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MEMORANDUM  FOR  UNDER  SECRETARY  OF  DEFENSE  (ACQUISITION  AND 
TECHNOLOGY) 

SUBJECT:  Report  of  the  1998  Defense  Science  Board  (DSB)  Task  Force  on  Open  Systems 


I  am  pleased  to  forward  the  final  report  of  the  1998  DSB  Task  Force  on  Open  Systems 
(OSTF).  This  effort,  chaired  by  Dr.  Wayne  L.  O’Hem,  Jr.,  was  formed  to  examine  the  benefits  of, 
criteria  for,  and  obstacles  to  the  application  of  an  Open  Systems  approach  to  weapon  systems,  and  to 
make  recommendations  on  revisions  to  DoD  policy,  practice,  or  investment  strategies  that  are 
required  to  obtain  maximum  benefit  from  adopting  Open  Systems. 

It  has  been  apparent  from  the  onset  of  the  study  that  an  OS  mindset  was  an  essential  core 
value  which  applied  broadly  across  the  DoD  and  not  just  to  the  engineering  of  weapons  systems. 
Already,  there  have  been  a  number  of  programs  which  have  leveraged  Open  Systems  concepts  and 
reaped  enormous  benefits.  However,  despite  the  pockets  of  good  work  and  salient  successes  within 
DoD,  the  Task  Force  has  concluded  that  the  Department  lacks  a  unifying  concept  and  a  solid 
foundation  from  which  to  rally  around.  As  a  result,  the  Task  Force  believes  that  there  is  little  hope 
of  achieving  many  of  the  DoD’s  key  objectives  without  a  massive  infusion  of  an  Open  Systems 
Process  (OS  Process)  into  its  affairs. 

The  challenges  facing  DoD  are  enormous,  but  so  are  the  benefits.  It  is  the  hope  of  the  OSTF 
that  DoD  leadership  aggressively  embrace  an  OS  Process  and  force  the  necessary  cultural  change. 

I  endorse  all  of  the  Task  Force’s  recommendations  and  propose  you  review  the  Task  Force 
Chairman’s  letter  and  report. 


Craig  L Fields 
Chairman 


ENSE  SCIENCE 
BOARD 


OFFICE  OF  THE  SECRETARY  OF  DEFENSE 

3140  DEFENSE  PENTAGON 
WASHINGTON,  DC  20301-3140 


30  September  1998 


Dr.  Craig  I.  Fields 
Chairman  DSB,  0USD(A&T) 

3 140  Defense  Pentagon,  Room  3D965 
Washington,  DC  20301-3140 

Dear  Dr.  Fields: 

Attached  is  the  final  report  of  the  DSB  Task  Force  on  Open  Systems.  The  Task  Force 
was  formed  to  examine  the  benefits  of,  criteria  for,  and  obstacles  to  the  application  of  an 
Open  Systems  approach  to  weapon  systems,  and  to  make  recommendations  on  revisions 
to  DoD  policy,  practice,  or  investment  strategies  that  are  required  to  obtain  maximum 
benefit  from  adopting  Open  Systems. 

The  Open  Systems  Task  Force  (OSTF)  found  this  to  be  a  challenging  assignment.  There 
already  existed  an  OSD  Joint  Task  Force  (OS-JTF)  which  has  done  marvelous  work 
introducing  the  commercial  Open  Systems  (OS)  experience  to  DoD.  There  have  been  a 
number  of  programs  which  have  leveraged  OS  concepts  and  returned  enormous  benefits. 
Examples  are  the  Army  Intelligence  and  Electronic  Warfare  Common  Sensor  program. 
Navy  submarine  combat  control  systems,  and  coordinated  DARPA,  Air  Force,  Navy,  and 
Marine  programs  for  a  common  processing  upgrade  for  F-15,  F-18,  and  Harrier. 

So  what  could  be  the  value-added  of  this  DSB  OSTF?  In  initial  discussions  with  Dr. 
Jacques  Gansler,  the  USD(A&T),  and  Mr.  Leonard  Burke,  Director  of  the  OSD  OS-JTF, 
each  cited  the  pockets  of  good  work  and  salient  successes  but  lamented  the  general  state 
across  DoD.  They  emphasized  the  need  for  a  unifying  concept,  a  solid  foundation  which 
DoD  could  rally  around.  This  became  the  primary  objective  of  the  OSTF. 

As  the  OSTF  identified  the  core  principles  of  OS,  it  quickly  became  apparent  that  an  OS 
mindset  is  an  essential  core  value  which  applies  broadly  across  the  Department,  not  just 
to  the  engineering  of  weapons  systems.  We  reviewed  a  number  of  DoD  objectives, 
ranging  from  evolving  concepts  of  warfare  as  envisioned  in  Joint  Vision  2010  and  the 
Service  equivalents,  to  Mr.  Cohen’s  Defense  Reform  Initiative,  to  Acquisition  Reform  — 
all  to  be  achieved  in  an  era  of  budget  distress.  We  were  struck  by  the  dependence  of 
these  priorities  on  the  attributes  provided  by  an  OS  approach  -  so  much  so  that  the  OSTF 
concludes  there  is  little  hope  that  such  priorities  can  be  achieved  without  a  massive 
infusion  of  an  Open  Systems  Process  (OS  Process)  into  the  affairs  of  the  Department. 
We  argue  that  an  OS  Process  is  a  cornerstone  of  the  solutions  that  will  be  needed  to  meet 
our  current  and  future  challenges. 


DoD  and  its  industrial  partners  have  extensive  competencies  and  an  effective  OS  Process 
is  well  within  grasp.  Ironically,  however,  it  is  the  opinion  of  most  interviewees  that 
success  is  highly  unlikely.  DoD  and  higher  level  oversight  processes  and  cultures  are 
dysfunctional  from  an  OS  perspective,  and  are  so  entrenched  that  fundamental  change  is 
thought  to  be  almost  impossible.  Implementing  a  strong  OS  Process  within  DoD  is 
primarily  and  institutional  matter. 

The  challenges  facing  DoD  are  enormous.  Fortunately,  so  are  the  demonstrated 
operational,  functional,  and  economic  benefits  of  OS  attributes.  With  a  need  so  great  and 
significant  relief  so  close  at  hand,  it  is  the  hope  of  the  OSTF  that  DoD  leadership 
aggressively  will  embrace  an  OS  Process  and  force  the  necessary  cultural  change. 

Many  people  made  significant  contributions  to  this  effort.  I  have  tried  to  acknowledge 
many  of  them  in  the  Foreword  to  this  Report.  Hopefully  they  find  their  hard  work  and 
expertise  reflected  in  the  attached  Report,  which  I  believe  provides  the  Department  with  a 
thoughtful  approach  for  addressing  a  very  important  issue. 

Sincerely, 

iIGHED 

Wayne  L.  O’Hem,  Jr.,  Ph.D. 

Chairman,  DSB  Task  Force  on  Open  Systems 
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FOREWORD 


Many  people  and  organizations  have  been  generous  in  assisting  the  DSB  Task  Force  on  Open  Systems  (OSTF).  Mr.  Peter  Marino 
started  as  Co-Chair  of  the  OSTF  before  being  asked  to  co-chair  another  effort.  His  direction,  insights,  and  support  were  of  great 
value.  Many  members  of  the  Defense  Science  Board,  including  Dr.  Craig  Fields,  Dr.  John  Foster,  Gen.  Larry  Welch,  USAF  (Ret), 
Dr.  George  Heilmeier,  the  Honorable  Anita  Jones,  VADM  Jerry  Tuttle,  USN(Ret),  Dr.  Robert  Cooper,  Mr.  William  Howard,  Jr.,  and 
Dr.  Michael  Frankel  contributed  significantly  to  our  efforts.  Mr.  John  Elio,  Maj.  Wynne  Waldron  and  Maj.  Tony  Yang  of  the  DSB 
staff  also  have  been  very  helpful.  The  OSD  Open  Systems  Joint  Task  Force  (OS-JTF)  has  been  behind  us  all  along  --  I  wish 
particularly  to  commend  the  contributions  of  Mr.  Leonard  Burke  and  Dr.  Chien  Huo.  Similarly,  we  received  extensive  support  from 
other  government  activities,  particularly  Program  Offices  and  Depots  which  very  much  need  the  benefits  of  an  Open  Systems 
Process.  Industry  provided  a  plethora  of  information,  and  in  many  instances  are  struggling  to  infuse  Open  Systems  approaches  within 
DoD  constraints.  Lastly,  I  wish  to  thank  to  the  members  of  the  OSTF,  listed  in  the  Report  and  in  Appendix  B,  who  put  so  much  into 
this  in  the  hope  that  DoD  really  can  change  when  it  is  important. 


Wayne  L.  O’Hem,  Jr.,  Ph.D. 
Chairman 

DSB  Task  Force  on  Open  Systems 


10/19/98  14:25 


DSB  OSTF  FINAL  REPORT 


page  4 


DSB  OSTF  FINAL  REPORT 


EXECUTIVE  SUMMARY 


Open  Systems  -  The  Commercial  Experience 

We  know  from  our  computing,  telecommunications,  electronic  entertainment,  and  local  building  codes  the  power  of  smart 
modularity.  Open  “Plug  &  Play”  architectures  (computers,  a  well-wired  home,  stereo  systems)  permit  us  to  configure, 
reconfigure  and  update  hardware  and  software  from  a  wide  range  of  general  purpose  and  specialty  suppliers.  Wide 
interchangeability  permits  niche  products  to  address  many  diverse  user  communities,  creating  a  large  aggregate  market  and 
fueling  massive  private  investment,  enabling  a  plethora  of  Commercial  Off  The  Shelf  (COTS)  products  at  previously 
unimagined  low  costs.  In  parallel,  a  new  networking  industry  has  sprung  up,  enabling  broad  interoperability  between  hosts 
which  are  not  otherwise  necessarily  compatible.  Thus  our  economy  and  culture  has  been  revolutionized  within  a  couple 
short  decades  and  our  institutions  and  citizens  have  achieved  a  quantum  leap  in  operations,  competitiveness,  and 
effectiveness. 

The  commercial  revolution  has  been  built  upon  the  concept  of  extensive  modularity,  driven  by  carefully  crafted 
architectures  implemented  at  various  tiers  throughout  the  product  chain.  Architectural  concepts  are  very  different  at  the 
several  levels  in  the  product  hierarchy.  Suppliers  strive  to  achieve  “Plug  &  Play”  interchangeability  within  their  product 
architectures  so  that  users  can  configure  and  upgrade  the  overall  system  with  components  (monitors,  speakers,  tires,  etc.) 
from  many  sources  according  to  individual  needs.  The  effectiveness  of  “Commercial  Plug  &  Play”  varies.  For  instance, 
Apple  is  relatively  narrowly  supported  but  has  good  interchangeability  within  their  architecture,  while  Microsoft  is  more 
widely  supported  but  generally  does  not  work  as  well.  Achieving  the  desired  degree  of  Plug  &  Play  requires  careful 
management  and  engineering  attention. 

Left  to  their  own  devices,  networking  the  Apple  and  Microsoft  lines  would  still  be  relatively  awkward.  A  whole  new 
industry  has  emerged  to  provide  broad  connectivity.  Diverse  user  products  can  now  be  connected  relatively  seamlessly 
through  the  Internet  and  new  wideband  telecommunication  architectures.  We  note  that  the  platform  suppliers  generally  did 
not  and  probably  could  not  supply  revolutionary  connectivity  -  that  came  from  outside  initiatives.  Further,  true 
interoperability  at  the  platform  level,  which  our  OSTF  refers  to  as  “Plug  &  Fight,”  does  not  derive  just  from  good 
connectivity,  for  protocols  and  applications  inside  the  platforms  also  have  to  be  compatible.  Not  only  must  our  computers 
talk  to  each  other,  but,  for  example,  my  MS  Word  program  must  accept  your  Word  Perfect  document.  Thus,  Plug  &  Fight 
can  not  be  achieved  just  by  providing  good  Plug  &  Play  platform  architectures.  There  needs  to  be  higher  order 
mechanisms  for  effective  interoperability  to  be  achieved. 

And  finally,  none  of  all  of  this  would  be  economically  feasible  without  the  massive  economies  offered  by  lower  tier  COTS 
components  —  microprocessors,  video  cards,  network  servers,  etc.  It  is  not  conceivable  that  individual  commercial  user 
communities  could  have  funded  unique  component  developments  for  their  individual  needs.  It  is  only  through  massive 
reuse  of  commercial  investment  across  many  applications  that  the  revolution  has  been  possible. 

Application  to  DoD 

There  are  important  parallels  for  DoD.  Indeed,  the  OSTF  has  found  that  many  commercial  OS  principles  and  practices 
have  direct  application  in  military  systems  and  that  great  benefits  would  accrue.  But  OS  are  not  just  Best  Business 
Practice.  We  note  that  the  new  operational  concepts  expressed  in  Joint  Vision  2010  (JV2010)  and  the  Service  equivalents 
envision  ad  hoc,  composite  forces  quickly  constituted  and  deployed  to  distant  lands,  requiring  extensive  interoperability 
corresponding  planning,  training,  transport,  and  sustainment-  true  force-level  “Plug-&-Fight.”  To  support  this  operational 
concept,  Forces  and  combat  support  systems  must  be  modular,  interchangeable,  and  interoperable.  Gen.  Larry  Welch 
observed  that  the  ability  to  readily  integrate  force  elements  as  needed  at  the  moment  is  usually  more  important  than  the 
final  increment  of  individual  performance. 

We  also  note  Defense  Reform  Initiative  objectives  of  OSD  and  USD(A&T)  such  as  reducing  ownership  costs  and 
acquisition  timelines  and  dealing  with  rapid  technological  obsolescence  —  all  to  be  accomplished  in  a  severe  budget 
environment  that  may  further  worsen.  Extensive  modularity,  driven  by  commercially  oriented  OS  Process  architectures, 
will  be  required  to  achieve  such  affordability  and  efficiencies. 

In  fact,  the  OSTF  argues  that  major  DoD  priorities  cannot  be  achieved  without  a  massive  infusion  of  OS  attributes  through 
an  organized  OS  Process.  Some  sort  of  OS  Process  must  become  a  DoD  mindset  and  core  competency. 
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The  required  infusion  of  an  OS  Process  must  manifest  in  three  important  ways: 

•  Continuous  Viability.  Forces,  systems,  and  processes  (ex.  logistics  management  systems)  must  be  configured  to 
economically  maintain  operational,  technical,  and  sustainment  viability  throughout  the  life  of  the  program.  Most 
legacy  stovepipe  solutions  are  not  viable  in  today’s  world  and  jeopardize  missions,  programs,  and  budgets. 

•  Architecture-Driven  Modularity.  It  is  clear  that  DoD  must  be  very  modular  at  the  Force,  system,  and  process  levels.  It 
is  essential  that  modularity  be  driven  by  smart  architectures  tailored  at  each  level  of  the  product  chain,  from  the  Force 
level  (ex.  for  interoperability)  through  intermediate  levels  to  systems  and  on  down  to  individual  supplier  components. 
The  architectural  hierarchy  itself  must  be  carefully  crafted  or  the  simultaneous  achievement  of  Plug  &  Fight,  Plug  & 
Play,  and  COTS  economies  will  be  lost. 

•  Manage  to  the  Natural  Cycle  Rates  of  the  Underlying  Components.  Classic  DoD  program  management  and  oversight 
processes  baseline  designs  down  to  the  piece  part  level  —  and  then  fiercely  resist  change  to  the  baseline.  In  an  era  of 
rapid  product  evolution  and  obsolescence,  this  approach  is  dysfunctional.  Without  refresh,  product  currency  cannot  be 
maintained  through  the  period  typically  needed  for  Engineering  and  Manufacturing  Development  (EMD),  much  less 
through  the  time  needed  for  test,  production,  fielding,  and  sustainment.  Rather  than  trying  to  resist  change,  DoD 
management  processes  must  proactively  enable  the  various  natural  change  rates  of  the  underlying  components.  This  is 
a  systemic  change  to  DoD  acquisition  philosophy  and  will  require  a  major,  orchestrated  revamping  of  system 
management  and  oversight  processes. 

Achieving  a  competent  OS  Process  ought  to  be  straightforward  for  DoD.  The  tenants  are  a  variation  upon  the  principles  of 
good  system  engineering  and  are  within  our  grasp.  It  is  primarily  the  institutions  and  culture  which  need  to  change,  and 
such  change  will  be  very  difficult. 

An  OS  Process  for  DoD 

The  OSTF  has  described  an  OS  Process  tailored  to  DoD  needs.  Because  the  field  of  Information  Technology  is  maturing 
the  understanding  of  Open  System  processes,  and  because  most  people  have  personal  experience  in  this  area  regardless  of 
their  individual  professional  pursuits,  this  report  will  tend  to  use  IT  examples  in  examining  the  axioms  of  an  OS  Process 
for  DoD.  But  the  urgent  need  for  and  benefits  of  the  OS  Process  described  here  apply  to  almost  all  forms  of  electronics, 
both  digital  and  analog,  and  most  other  disciplines  such  as  mechanical,  hydraulic,  and  pneumatic. 

The  OSP  is  based  upon  a  hierarchy  of  architectures  to  capture  the  three  basic  Open  Systems  attributes  —  Plug  &  Fight, 
Plug  &  Play,  and  ready  use  of  COTS. 

Hierarchy  of  Architectures.  In  the  commercial  example,  Plug  &  Fight  is  represented  by  industry  architectures  such  as 
ATM  for  telecommunications  and  the  Internet  and  Web  for  networking.  Establishing  Plug  &  Fight  interoperability  is  a 
challenge  distinct  from  achieving  Plug  &  Play  systems  and  can  only  be  achieved  by  a  high  order  mechanism  to  force 
architectures  and  standards  which  are  truly  compatible.  For  example,  both  Apple  and  MS  Windows  can  claim  to  enable 
Plug  &  Play  within  their  own  architectures,  but  cannot  by  themselves  provide  rich  interoperability  --  that  comes  from  the 
telecommunications  and  networking  industries,  the  Plug  &  Fight  levels. 

Various  DoD  systems  claim  to  be  interoperable  because  they  use  widely  accepted  connectivity  standards.  But  they  use 
different  connectivity  standards  which  are  not  fully  compatible,  and  interpret  common  standards  differently;  hence,  the 
systems  are  not  truly  fully  interoperable.  To  achieve  true  interoperability  across  the  forces,  OSD  and  JCS  must  impose  and 
rigidly  enforce  a  single  set  of  mutually  compatible  and  implemented  standards,  without  compromise,  in  each  domain  such 
as  C4ISR  and  logistics  management  systems. 

In  the  OSTF’s  architectural  hierarchy  example,  OSD  and  JCS  impose  mandatory  architectures  at  the  highest  level  to  assure 
interoperability  across  the  Forces  in  each  relevant  domain,  such  as  logistics  management,  mission  planning,  etc. 

A  second  level  tier  would  enable  DoD-wide  system-of-systems  requirements  such  as  Cruise  Missile  Defense  or  a  Single 
Integrated  Air  Picture.  Similarly,  at  the  next  lower  tier  PEOs  may  impose  architectures  for  cross-system  needs  such  as 
commonality  —  e.g.  common  electronic  board  formats  in  combat  vehicles. 
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At  the  platform  system  level  the  system  architecture  is  still  controlled  by  the  Systems  Program  Office  through  the 
traditional  and  well-proven  Configuration  Control  Board  (CCB).  The  Program  Office  objective  is  to  be  compliant  with 
higher  tier  Plug  &  Fight  requirements,  to  enable  Plug  &  Play  throughout  the  system,  and  capture  the  benefits  of 
commercial  components.  Open  components  are  accommodated  by  configuring  the  system  to  include  a  carefully 
orchestrated  set  of  Form,  Fit,  Function,  and  Interface  (F3I)  “sockets.”  The  F3I  approach  permits  the  overall  structure  of  the 
system  to  be  controlled  without  specifying  the  detailed  configuration  at  the  assembly  and  component  levels. 

This  is  the  major  change:  the  Program  Office  enables  Plug  &  Play  by  ceding  control  of  the  detailed  configuration  to  the 
prime  contractor  and  suppliers.  Contractor  and  supplier  control  of  the  detailed  configuration  is  absolutely  necessary  to 
capture  the  economic  advantages  of  COTS,  enable  technology  refresh,  and  deal  with  parts  obsolescence  and  a  diminishing 
supplier  base.  Without  this  attribute,  DoD  systems  will  continue  to  suffer  nearly  insurmountable  affordability  and 
supportability  problems. 

Administering  the  Architectures.  The  example  OS  Process  outlined  in  this  Report  relies  upon  the  existing  line 
management  structure,  augmented  at  each  tier  by  advisory  Architectural  Control  Boards  (ACBs)  patterned  after  the  proven 
CCB  process  used  by  Systems  Program  Offices.  Line  Authority  establishes  requirements  and  performance  based 
expectations  —  the  “why”  --  while  lower  echelons  develop  the  “how.”  As  with  the  Program  Office  CCB,  the  ACB  acts  as  a 
control  point  advising  the  Line  Authority  on  compliance  before  all  milestone  reviews  and  key  decisions. 

An  ACB  would  be  established  at  each  organizational  echelon  having  responsibility  for  an  architecture  in  the  hierarchy. 
This  would  be  an  additional  role  for  the  OSD/JCS  ACC  and  the  Program  Office  CCB. 

Partitioning  for  modularity  is  already  largely  understood  from  the  system  engineering  process  necessary  for  system  and 
complex  software  development.  Like  large  software  builds,  OS  will  be  unforgiving  of  poor  architectures  and  partitioning. 
Similarly,  interface  standards  must  be  chosen  carefully.  While  Openness  is  always  desired,  wide  use  is  the  more  important 
attribute.  Thus  the  OSTF  recommends  DoD  pursue  “Practical  Open”  solutions. 

Risks  of  Open  Approaches.  There  are  of  course  risks  to  adopting  OS  approaches.  In  return  for  the  enormous  economic 
and  schedule  advantages  of  Open  standards,  DoD  cedes  some  significant  degree  of  control  to  others.  DoD  needs  to  be 
proactive  early  in  the  standards  definition  process.  When  it  has  done  so,  it  has  often  been  effective.  DoD  requirements 
often  lead  commercial  standards.  However,  programs  may  have  to  pick  standards  before  the  eventual  free  market  winners 
are  known.  The  program  may  guess  wrong,  and  have  to  be  changed  over  to  the  winning  standard.  In  most  cases,  however, 
DoD  is  far  better  off  guessing  which  standards  will  be  commercially  adopted  and  recovering  when  wrong,  than  funding  the 
development  and  support  of  its  own  unique  solutions.  Also,  as  standards  eventually  become  obsolete,  migration  plans  will 
be  necessary. 

Applying  an  OS  Process  to  subsystem  upgrades  of  legacy  systems  —  the  bulk  of  the  DoD  inventory  --  can  be  quite 
expensive.  The  problem  is  not  so  much  the  upgrade  itself,  but  integrating  the  upgrade  with  the  residual  legacy  architecture 
of  the  system  and  other  interfacing  subsystems.  This  can  be  particularly  difficult  when  the  residuals  are  proprietary,  often 
the  case  in  legacy  systems. 

By  far  the  greatest  risk  of  an  OS  Process  is  the  rigidity  of  current  U.S.  government  management  and  oversight  processes. 
These  are  self-inflicted  and  entrenched.  Experience  shows  that  Program  Offices  can  achieve  astounding  results  when 
permitted  to  do  so. 

Managing  to  Let  OS  Happen.  We  are  in  an  era  of  extraordinary  technology  advances  providing  astounding  performance, 
packaging,  and  cost  improvements.  This  should  be  a  boon  to  DoD,  facilitating  skyrocketing  capabilities,  falling  prices,  and 
accelerating  schedules.  But  DoD  is  not  realizing  the  benefits  of  these  revolutions.  More  typically,  DoD  systems  become 
antiquated  before  they  are  fielded,  parts  are  obsolete  and  unobtainable,  support  is  a  nightmare,  costs  soar,  and  the  program 
becomes  only  marginally  viable,  jeopardizing  missions,  programs,  and  budgets.  This  is  the  result  of  dysfunctional 
management  processes  which  must  be  revamped. 

Systems  need  to  be  parsed  and  managed  by  the  natural  cycle  rates  of  the  underlying  components.  Some  aspects,  like  basic 
structure  (hulls,  airframes),  change  infrequently  throughout  the  life  of  the  system  Other  elements,  like  basic  subsystem 
architectures  and  interfaces,  computer  operating  systems  and  language,  have  a  moderate  change  rate  —  perhaps  15  years  or 
so.  As  we  know  all  too  well,  elements  such  as  electronic  components  can  have  very  high  cycle  rates,  sometimes  less  than 
two  years.  But  DoD  processes  are  suited  only  to  very  slow  evolution  and  infrequent  change. 
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DoD  needs  to  revamp  its  management  process  to  coincide  with  and  enable  the  natural,  asynchronous  cycle  rates  of  the 
underlying  subsystems  and  components.  Configuration  “snapshots”  will  be  defined  when  particular  products  (ex.  first 
flight  article)  are  needed.  It  is  not  expected  that  subsequent  articles  would  have  identical  detailed  configurations.  Systems 
will  be  defined  by  (1)  functional  specifications,  (2)  the  configuration  of  low  and  medium  cycle  rate  elements,  (3)  F3I 
“sockets”  for  high  cycle  rate  elements,  and  (4)  migration  plans  to  maintain  continuous  system  viability. 

Is  such  a  structure  of  decoupled  system  elements  plausible  in  the  product  domain?  The  OSTF  considered  the  stress  case  of 
avionics  for  high  performance  tactical  aircraft,  a  major  DoD  expense.  Layered  software  architectures  were  found  which 
enable  portability  across  hardware  hosts  and  ready  turnover  of  application  programs.  In  the  hardware  domain, 
consolidated,  well  interconnected  electronics  enclosures  located  centrally  in  the  fuselage  and  outboard  equipment  bays  can 
now  provide  high  performance  commercial  backplanes  to  allow  subsystem  electronics  to  evolve  with  minimum  need  for 
Group  A  (airframe)  modifications.  The  OSTF  concludes  that  product  configurations  which  enable  natural  cycling  of 
system  elements  are  indeed  available  for  most  DoD  applications. 

OS  Process  Status  Within  DoD.  The  OSTF  has  suggested  a  new  way  of  thinking  about  configuring  Forces  and  systems, 
and  managing  development  and  logistics  programs.  Being  new,  one  might  expect  adoption  within  DoD  to  be  modest  at 
best  and  that  is  very  much  the  case.  At  the  Force  level,  OS  attributes  are  considered  only  narrowly  (ex.  C4ISR 
interoperability)  and  are  not  embraced  as  a  broad  enabler,  even  in  areas  of  seeming  great  importance  such  as 
interoperability  of  logistics  management  systems.  The  OS  Process  is  not  seen  as  a  cornerstone  competence,  a  highly 
leveraged  solution  for  long-term  viability  and  effectiveness.  Although  there  are  heartening  grass  roots  efforts  such  as  the 
Pacific  Fleet  command  ships,  within  the  new  warfighting  initiatives  such  as  JV2010  and  the  service  equivalents  there  is 
little  substantive  funding  of  real  projects.  Within  the  operational  community  we  found  few  of  the  requisites  for  a  real 
initiative,  such  as  plans,  metrics,  training,  and  investment. 

Within  the  acquisition  and  support  community  there  are  exciting  examples  of  truly  inspired  work;  but  looking  across  DoD 
as  a  whole,  progress  is  minimal.  OS  attributes  are  not  genuinely  embraced  and  demanded  by  the  Services  and,  as  with  the 
operational  community,  the  requisites  are  not  in  place.  Legacy  systems  are  particularly  disadvantaged  due  to  the  lack  of 
funds  to  upgrade  system  architectures.  The  support  community  is  in  extremus.  In  cases  where  the  very  survival  of  a 
system  is  threatened,  such  as  the  predecessors  of  the  Army  IEWCS  and  the  Navy  submarine  combat  control  system. 
Program  Offices  have  been  permitted  to  make  quantum  advances  and  have  achieved  notable  successes.  However,  these 
techniques  are  not  widely  institutionalized. 

Revamping  Program  Management  and  Oversight  Processes  Capturing  the  OS  nuggets  of  (1)  continuous  viability  of  Forces 
and  systems,  (2)  architecture-driven  modularity,  and  (3)  managing  to  the  natural  cycle  rate  of  the  contributing  elements, 
will  require  an  extensive  revamping  of  DoD  program  management  and  oversight  processes.  An  OS  Process  must  become 
a  mindset  and  core  value  of  DoD.  We  have  dead-end,  stove-pipe  systems  because  we  demand  and  reward  little  more.  The 
requirements  process  must  demand  OS  attributes. 

The  very  concept  of  what  a  system  is  must  change  from  a  static  “point-solution”  view  to  thinking  of  systems  as  crucibles  to 
capture  and  exploit  the  explosive  beneficial  change  occurring  all  around  us. 

Today,  to  be  static  is  become  obsolete  and  at  risk.  Yet  DoD  management  and  oversight  processes  massively  impede  the 
dynamism  DoD  so  desperately  needs.  The  concept  of  baselining  is  as  important  as  ever,  but  needs  to  be  redefined.  Rather 
than  the  historic  detailed  configuration  control,  products  needs  to  be  baselined  to  functional  specifications,  an  architecture, 
F3I  interface  specifications,  and  a  migration  plan  for  continuous  viability. 

Revamping  of  contracting,  the  EMD  process,  test  and  evaluation  philosophy,  and  internal  and  external  oversight  is 
required.  Contract  structures  need  to  be  realigned  to  conform  with  the  architectural  partitioning.  DoD  and  congressional 
milestone  exit  criteria  need  to  be  revised. 

Funding  categories  (“color  of  money”)  are  particularly  dysfunctional.  Technology  turnover  and  obsolescence  problems 
transcend  the  classic  funding  categories  and  should  be  managed  as  an  integrated  whole.  Program  Managers  need  not  only 
full  life  cycle  responsibility,  but  corresponding  authorities  and  resources.  Color  of  money  issues  are  crippling  and  are 
being  separately  addressed  by  OSD.  The  OS  Process  adds  further  urgency. 
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A  glimmer  of  hope  is  offered  by  industry.  When  business  is  truly  threatened,  industry  has  often  done  well  leveraging  Open 
Systems,  to  the  extent  permitted  by  DoD  procedures.  DoD  should  seek  to  leverage  the  enormous  capabilities  of  industry. 

Implementing  an  OS  Process:  Incentives  and  Disincentives.  Implementation  ought  to  be  easy:  the  technology  and 
methodology  is  before  us.  However,  implementation  will  not  be  easy  because  the  impediments  are  largely  institutional, 
self-inflicted  and  entrenched.  Current  DoD  processes  impose  massive  impediments.  The  notable  successes  which  have 
been  cited  are  monuments  to  constructive  circumvention.  DoD  has  legions  of  very  good  and  motivated  people:  the  most 
effective  thing  that  can  be  done  is  merely  to  get  out  of  the  way,  to  unshackle  the  work  force.  But  DoD  processes  are  so 
entrenched  that  unshackling  will  not  happen  without  aggressive  executive  leadership. 

Recommendations  This  OSTF  recommends: 

•  A  Special  Assistant  for  OS  Process  Implementation  be  established  within  the  immediate  office  of  the  SecDef, 
perhaps  reporting  to  the  DepSecDef. 

•  The  new  Special  Assistant  develop  a  roadmap  to  (1)  establish  a  formal  OS  Process  to  be  mandated  for  all  new  and 
legacy  system  upgrades,  (2)  revamp  management  and  oversight  processes,  (3)  establish  incentives,  and  (4)  attack 
impediments. 

•  In  the  meanwhile  there  are  some  immediate  actions  which  can  be  taken: 

•  The  JCS  amend  all  MNS  and  ORDS  to  require  OS  Process  attributes  and  continuous  system  viability 

•  The  USD(A&T)  and  ASD(C4I): 

•  Direct  all  system  programs  to  develop  a  Viability  Risk  Mitigation  Program 

•  Grant  interim  relief  from  legacy  management  processes  to  permit  Program  Managers  to  adopt 
preliminary  OS  Processes 

•  Establish  Architecture  Control  Boards  with  supporting  structure  for  each  key  architecture 

•  Designate  a  few  pathfinding  OS  Process  major  programs 

•  Establish  a  process  for  consistent  DoD  participation  in  commercial  Standards  processes 

•  Include  an  OS  Process  module  in  DoD  professional  education 

•  Expand  OS-JTF  role  and  capabilities  to  become  the  secretariat  for  the  new  Special  Assistant 

•  Establish  a  DoD/Industry  OS  Process  Coordination  and  Advisory  Council 

•  SecDef  hold  kickoff  offsite  with  Chairman,  Service  Secretaries,  Chiefs,  CAE  to  secure  personal  commitment, 
launch  DoD  initiative,  request  Congressional,  Administration,  and  Industry  support 
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Tasking 

•  Formal  Terms  of  Reference* 

-  What  are  benefits  and  obstacles  to  an  Open  Systems  Process? 

-  What  would  we  have  to  do  to  realize  the  benefits? 

-  New  and  legacy  systems;  not  just  IT 

•  Initial  discussions  with  USD(A&T),  OS-JTF 

-  “DoD  has  been  working  on  Open  Systems  --  this  is  important,  but  we 
haven’t  gotten  our  arms  around  it” 

-  “Need  the  Task  Force  to  recommend  a  conceptual  framework  for 
proceeding” 


This  is  not  an  esoteric  report  about  formal  “Open  Systems”  — 

It  is  about  exploiting  Lessons  Learned  from  the  Open  Systems  experience 
to  achieve  a  major  advance  in  DoD  combat  and  acquisition  effectiveness 


iwi9/9s  u:23  *  See  Appendix  A  to 


•  Terms  of  Reference  -  Defense  Science  Board  Study  Task  Force  on  Open  Systems,  1 4  July  1 997 

-  Examine  benefits  of,  and  obstacles  to,  application  of  OS  Approach 

-  Examine  application  to: 

•  New,  developed,  and  fielded  programs 

•  Across  the  spectrum  of  systems,  not  just  IT 

•  Initial  discussions  with  the  USD(A&T)  and  the  Director  of  OS-JTF  addressed 

-  What  process  needed  to  get  broad  acceptance 

-  Recommend  revisions  to  DoD  policy,  practice,  and  investment  strategies 
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Conclusions 

•  Open  Systems  Process  is  fundamental  to  many  DoDpriorities  that  are  dependent  upon  a 
process-based  approach 

-  JV  2010  and  Service  equivalents  -  Reduced  cycle  time  and  ownership  costs 

-  Force  modernization  -  Favorable  industrial  base  realignment 

Open  Systems  Process  is  a  Warfighting  and  Title  10 essential  core  value 

•  Forces,  systems,  and  processes  need  to  leverage  change: 

-  Configure  Forces,  systems  and  processes  for  continuous  viability 

-  Achieve  architecture-driven  modularity 

-  Manage  to  the  natural  cycle  rates  of  underlying  components 

•  Open  Systems  Process  is  based  upon  a  hierarchy  of  architectures  and  standards  developed 
with  a  performance-based  collaborative  approach 

•  Unlikely  that  DoD  can  implement  Open  Systems  Process  by  usual  bureaucratic  means 

-  Open  Systems  Process  is  a  cultural  and  budget  challenge-  process  is  within  our  grasp 

-  Requires  support  from  DoEt  Administration,  Hill,  and  Industry 

-  Need  to  reconfigure  Forces,  systems,  and  management  processes 

-  Removing  impediments  is  most  important 

^^tequire^gg^^^nMdership|^^D^^^^e^ic^ecrete^champion^^| 
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Although  not  yet  widely  recognized,  a  number  of  DoD  priorities  can  be  achieved  only  with  a  massive  infusion  of  an  OS 
Process  and  related  investment  to  implement  OS  architectures.  Example  priorities: 

JV  2010  and  the  Service  equivalents  are  highly  dependent  upon  rapid,  collaborative  responses  with  distant  ad  hoc  forces 
and  all  the  associated  planning,  deployment,  and  sustainment  tasks  ~  which  are  in  turn  dependent  upon  a  genuine  Plug 
&  Play  capability  across  the  Forces. 

•  Force  Modernization  is  severely  strained  in  the  current  budget  and,  in  the  opinion  of  some,  may  worsen 
dramatically.  The  economies,  expediencies,  and  ability  for  tech  refresh  will  be  essential  for  programs  to  be  sold 
and  remain  viable. 

•  Reduced  Acquisition  Cycle  Time  and  Total  Ownership  Cost  are  being  driven  in  the  wrong  direction  by  recent 
developments  such  as  a  consolidating  industrial  base,  uneconomic  lot  buys,  dwindling  supplier  base,  and  program 
redirections.  OS  is  a  common  denominator  which  can  dramatically  improve  both  Acquisition  Cycle  Time  and  Total 
Ownership  Cost  by  leveraging  existing  architectures  and  commercial  investment  and  market  volume. 

•  Maintaining  competition  in  the  middle  industrial  tier  is  a  concern  for  DoD  with  consolidation  at  the  large  system 
tier.  Middle  tier  contractors  are  under  pressure  from  reduced  budgets  and  increased  use  of  COTS  at  the  component 
level.  An  OS  Process  can  potentially  serve  both  DoD  and  industry  by  nurturing  middle  tier  competitive 
opportunities. 

OS  and  the  OS  Process  is  not  just  an  “OSD/JCS  joint  thing”  —  it  must  be  recognized  as  an  essential  core  value  for 
Service  Warfighting  and  Title  10  responsibilities. 

DoD  Forces,  systems,  management  processes,  and  oversight  mechanisms  are  too  oriented  toward  static  solutions  for  a 
static  world,  defying  the  realities  of  today’s  world.  Such  an  orientation  is  a  road  to  failure,  as  seen  all  around  us  in  force 
deployment  problems  and  programs  at  great  risk  for  being  no  longer  viable.  DoD  Forces,  systems,  management 
processes  and  oversight  mechanisms  all  must  be  re-envisioned  and  reconfigured  to  leverage  change  so  as  to  remain 
viable  throughout  the  entire  life  of  the  Forces  and  systems. 
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Specifically,  we  need  to  reconfigure  Forces,  Systems,  and  key  processes  to  enable  continuous  evolution  for  life-long 
viability.  Continuous  evolution  can  be  economically  and  technically  achieved  only  through  extensive  use  of  smart, 
architecturally-driven  modularity,  whereby  Force  and  systems  are  seen  as  a  structure  of  F3I  “sockets”  to  enable  the 
natural  cycle  rates  of  the  underlying  components. 

Finally,  DoD  management  and  oversight  processes  must  be  revamped  to  enable  the  needed  continuous  evolution  from 
requirements  generation  and  system  concept  development  through  field  logistics  support.  Current  processes  are  hostile 
to  the  needed  OS  measures.  The  recommended  OS  Process  is  based  upon  a  hierarchy  of  architectures  and  their 
associated  interface  standards.  A  well  crafted  hierarchy  is  necessary  to  simultaneously  achieve  the  benefits  of  Plug  & 
Fight,  Plug  &  Play,  and  the  economies  of  commercial  components.  These  are  each  unique  attributes  with  their  own  sets 
of  enabling  conditions.  The  architectures  required  to  achieve  each  attribute  are  different  and  must  all  be  carefully 
coordinated  or  they  will  thwart  each  other. 

Each  architecture  and  the  associated  interface  standards  should  be  developed  and  maintained  with  a  performance-based 
collaborative  approach  in  which  Line  Authority  establishes  the  end  objectives  —  the  “what”  —  and  the  stakeholders 
determine  the  “how.” 

Although  the  basics  of  OS  Process  are  in  hand  and  readily  understood,  DoD  will  not  achieve  widespread 
implementation  by  its  natural  processes.  OS  Process  is  an  institutional  challenge.  DoD  must  revamp  a  number  of 
processes,  something  DoD  does  only  with  great  pain.  The  transformation  needs  to  include  oversight  processes  as  well 
and  will  require  support  from  throughout  DoD,  the  Administration,  and  the  Hill.  Industry  will  have  a  large  role  to  play 
and  that  support  should  be  requested. 

This  DoD  OSTF  and  the  OS-JTF  have  each  concluded  that  that  establishing  real  incentives  and  removing  the 
impediments  to  OS  implementation  is  a  critical  requirement.  Each  Task  Force  has  identified  a  number  of  impediments 
and  these  should  be  explicitly  attacked. 

These  are  radical  recommendations  for  DoD  and  successful  implementation  will  require  aggressive  leadership, 
championed  by  the  SecDef  and  Service  Secretaries. 
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Some  Terms 

•  A  remarkably  small  vocabulary  is  used  with  little  differentiation  to  describe  a 
broad  range  of  concepts,  hindering  critical  thinking  and  effective  communication 

•  For  this  report  we  use  the  following  terms  to  differentiate  key  concepts: 

-  Plug  &  Fight  (Force  Level)  or  Plug  &  Play  (Component  Level):  The  ability  to  readily 
incorporate  functionally  compatible  parts  on  short  notice 

-  Open  Systems  Process  (OS  Process):  The  process  of  achieving  Plug  &  Fight/Play 

-  Architecture:  The  overall  structure  of  a  solution 

-  Open:  Modular  architectures  with  completely  defined  and  publicly  available  interfaces, 
supported  by  consensus-based  standards 

-  Openness :  The  degree  to  which  an  architecture  or  standard  is  open 

-  COTS:  A  commercial  catalog  item  —  COTS  is  not  necessarily  Open 

-  Practical  Open:  Most  practical  [vs.  most  pure]  Openness 

-  F1!:  Specifying  Form,  Fit,  Function,  and  Interface  (F3I)  to  permit  Plug  &  Fight/Play 


The  maturity  of  a  discipline  is  often  reflected  in  the  richness  of  its  taxonomy.  For  example,  it  is  said  that  Eskimos  have  more  than 
thirty  words  to  describe  snow.  By  this  measure,  the  general  field  of  OS  is  still  very  much  in  an  infant  state.  The  OSTF  has  found  that 
while  a  number  of  sophisticated,  multidisciplinary  concepts  need  to  be  carefully  understood  and  treated  with  precision,  the  working 
vocabulary  with  which  to  accomplish  this  is  on  the  order  of  only  a  half  dozen  phrases.  The  lack  of  a  specific  vocabulary  and 
definitions  greatly  hindered  effective  communication  with  our  many  contributors  and  within  the  OSTF,  and  confounded  critical 
thinking.  Therefore,  for  the  purposes  of  this  Report  we  have  adopted  the  following  specific  terms  to  differentiate  between  critical 
concepts: 

Plug  &  Play  is  the  ability  to  readily  integrate  the  components  of  a  modular  system  as  needed  at  the  moment.  This  modularity  enables 
graceful  evolution  of  the  system  to  meet  changing  circumstances,  and  ready  adaptation  in  times  of  stress. 

Plug  &  Fight  is  the  Force-level  equivalent  of  “Plug  &  Play"  and  is  the  ability  to  constitute  and  integrate  force  elements  as  needed  at 
the  moment.  Widely  implemented  in  U.S.  forces,  this  attribute  would  enable  the  type  of  quick  reaction,  ad  hoc  expeditionary 
operations  envisioned  by  JV  2010  and  the  Service  equivalents. 

Architecture.  An  architecture  defines  the  overall  structure  of  an  entity  and  its  components,  and  the  interrelationships  of  the 
components.  OS  architectures  rely  on  physical  modularity  and  functional  partitioning  of  both  hardware  and  software  based  upon  well 
controlled  F3I  interfaces  to  enable  Plug  &  Play  and  Plug  &  Fight. 

Open.  Open  indicates  the  pure  case  of  architecture-driven  modularity  where  the  architecture  and  interfaces  are  well  defined  by  public 
interfaces  maintained  by  consensus-based  processes. 

Openness.  The  degree  to  which  an  architecture,  interface,  or  module  is  Open  in  the  pure  sense  of  the  word. 

Practical  Open.  In  choosing  architectures  and  standards,  there  are  many  considerations  in  addition  to  the  degree  of  Openness  --  for 
example,  how  well  adapted  the  standard  is  in  the  intended  community,  the  maturity  and  expected  continued  support  of  the  standard,  etc. 
The  OSTF  refers  to  the  optimum  balance  of  these  sometimes  conflicting  factors  as  “Practical  Open." 

F3I.  An  modular  system  can  be  thought  of  as  a  structure  of  “sockets”  which  permit  individual  modules  to  be  changed  when  needed  and 
to  evolve  at  their  own  natural  pace,  so  long  as  the  socket  discipline  is  strictly  maintained.  Individual  sockets  are  defined  by  a  Form,  Fit, 
Function,  and  Interface  (F3I)  specification  which  is  strictly  enforced  within  the  system-level  architecture 
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Why  Do  We  Care? 

•  Here  is  what  the  leadership  has  said: 

-  JV  2010:  “Applications  of  new  technology  will  transform  the  traditional  functions 
of  maneuver,  strike,  protection,  and  logistics.  These  transformations  will  be  so 
powerful  that  they  become,  in  effect,  new  operational  concepts  ....  These 
operational  concepts  will  provide  our  forces  with  a  new  conceptual  framework.” 

-  Concept  for  Future  Joint  Operations:  "The  key  characteristic  we  seek  for  our 
Armed  Forces  is  the  ability  to  conduct  dominant  operations  across  the  full  range  of 
possible  missions.” 

-  Secretary  Cohen:  “In  March,  I  went  out  to  see  the  U.S.  Army’s  Force  XXI 
experiments  ....  It  was  an  awe-inspiring  demonstration  ....  Force  XXI  is  the 
much-vaunted  Revolution  in  Military  Affairs  made  real ....  I  knew  that  the 
technology  I  was  seeing  was  key  to  U.S.  military  superiority  in  the  future.” 


But  DoD  is  already  on  a  downward  spiral,  even  with  today’s  missions ...  i 

It  is  unlikely  that  either  JV2010  or  the  Revolution  in  Military  Affairs  can  occur  j 
without  a  major  change  in  how  we  configure  our  Forces,  Systems,  and  Processes  | 

- ■ - .umu* . . . . ^ -,=■ - . . . - — J 


It  is  the  view  of  the  OSTF  that  Joint  Vision  2010  (JV2010)  represents  a  sound  and  thoughtful  roadmap  to  the  future  for 
DoD  as  it  works  its  way  through  the  thicket  of  uncertainties  and  alternative  futures  that  it  faces  in  the  aftermath  of  the  Cold 
War.  While  accommodating  change  is  always  difficult,  the  new  and  uncertain  world  which  has  resulted  from  the  fall  of  the 
Soviet  Union  presents  DoD  with  one  of  the  most  significant  discontinuities  it  has  ever  faced. 

The  end  state  that  JV2010  describes  is  composed  of  the  aggregate  capabilities  that  our  forces  must  posses  to  ensure  U.S. 
military  superiority,  leadership,  and  the  security  and  prosperity  of  the  American  people  in  the  21st  century.  JV2010 
describes  an  end-state  set  of  capabilities  which  are  radically  different  from  those  our  forces  possess  today. 

It  is  clear  that  DoD  has  expended,  and  is  still  expending,  significant  resources  in  the  process  of  thinking  about  the  future 
and  attempting  to  understand  what  qualities  and  attributes  our  forces  must  possess  to  maintain  military  superiority  in  the 
21st  century. 

It  is  equally  clear  that  it  is  unlikely  that  either  JV2010  or  the  Revolution  in  Military  Affairs  will  occur  without  a  major 
change  in  how  we  configure  our  forces,  systems,  and  processes. 
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Why  We  Care 

-  Warfighting. - 

•  Emerging  CONOPS  will  be  pick-up  actions:  collaborative,  quick  responses  to 
uncertain  enemies  in  remote,  poorly  understood  locations  with  little  infrastructure 

-  Ability  to  quickly  integrate  and  execute  will  be  a  corewarfighting  competency 

-  Quick  response  requires  ability  to  constitute,  configure,  and  execute  Forces  on  the  run 

-  Highly  integrated,  mutually  dependent,  joint  operations  with  coalition  Forces 

•  CONOPS  massively  dependent  upon  ready  constitution,  dynamic  collaborative 
planning  and  execution,  and  JV2010-style  sustainment 

•  Can’t  get  there  from  here  without  a  quantum  increase  in  Plug  &  Fight  capabilities 
across  the  force:  training,  planning,  deployment,  ops,  sustainment,  support 

•  Analogous  to  Reliability  for  the  Air  Force  in  early  ‘80s 

“The  high  availability  of  our  front  line  aircraft  was  a  major  factor  in  the  outstanding  Air  Force 
performance  in  Desert  Storm!  Plug  &  Fight  has  a  similar  potential  for  quantum  improvement 
and  could  be  our  next  great  leap  forward” 

General  (Ret)  Larry  Welch,  former  Chief  of  Staff.  U.S.  Air  Force 

IO/19AI  J4:2J 


Future  military  operations  are  likely  to  be  rapidly  unfolding,  pick-up  actions  that  require  collaborative,  quick  responses  to 
uncertain  conditions  in  remote,  poorly  understood  places  with  very  little  (or  no)  infrastructure  to  support  military 
operations.  Success  will  dependent  upon  our  ability  to  quickly  constitute,  configure,  and  execute  forces  on  the  run.  Our 
structure  will  require  mutually  dependent,  joint  operations  between  the  Services  and  coalition  forces.  They  will  be 
massively  dependent  upon  ready  constitution,  dynamic  collaborative  planning  and  execution,  and  the  Focused  Logistics 
envisioned  in  JV2010.  The  old  approach,  although  highly  successful  in  its  time,  simply  will  not  work  well  enough  to 
ensure  success  in  the  emerging  warfighting  environment. 
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Why  We  Care 

-  Title  10,  Training  and  Equipping  the  Force  - 

•  Acquisition  and  Support 

-  Current  processes  are  based  on  a  world  which  no  longer  exists 

•  Requirements  and  technology  evolved  slowly  in  most  areas 

•  Parts  presumed  to  be  available  at  reasonable  costs  over  long  periods 

•  Could  repair,  rebuild,  or  replace  from  detailed  drawings,  part  lists 

-  Although  these  conditions  no  longer  exist,  our  processes  haven’t  changed 
accordingly 

-  Our  acquisition  and  support  centers  are  in  extremis 

•  Train-As-You-Fight 

-  If  training  with  component,  joint,  and  coalition  Forces  is  to  be  effective,  Forces 
must  be  much  more  Plug  &  Fight-capable  than  they  are  today 


Equipping.  DoD  acquisition  processes  continue  to  echo  the  Cold  War  world  in  which  performance  mattered  more  than 
cost;  requirements  and  technology  evolved  slowly  in  most  areas;  parts  were  presumed  to  be  available  at  reasonable  costs 
over  long  periods;  and  industry  and  government  depots  could  repair,  rebuild,  or  replace  systems  from  detailed  drawings 
and  part  lists. 

Although  these  conditions  no  longer  exist,  our  processes  haven’t  changed  accordingly.  Program  managers  continue  to  be 
incentivized  according  to  the  old  standards,  with  predictable  poor  results. 

Our  acquisition  and  support  centers  suffer  particularly  from  the  rigidity  and  inflexibility  of  legacy  processes.  Those 
processes  are  based  on  the  assumption  that  repair  parts  and  other  materiel  needed  in  the  support  centers  remain  available. 
Today,  components  come  and  go  in  the  marketplace  so  rapidly  that  much  of  the  documentation  used  by  repairers  is  out  of 
date  by  the  time  they  receive  it.  If  this  trend  continues,  and  the  cycle  time  for  new  technologies  continues  to  shorten,  then 
it  is  highly  likely  that  support  centers  will  become  gridlocked  in  the  course  of  normal  operations  —  never  mind  the  loss  of 
wartime  surge  capacity. 

Training.  If  we  are  to  train  today  as  we  expect  to  fight  in  the  future,  then  training  with  other  U.S.  and  coalition  forces 
must  have  a  much  higher  Plug  &  Fight  content  than  is  the  case  today.  It  is  necessary  that  our  forces  train  on  each  others’ 
equipment.  Otherwise,  the  level  of  integration  needed  to  blend  disparate  units  together  on  short  notice  —  leaving  little  time 
to  train  —  will  not  be  achieved. 
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Why  We  Care 

-  Conclusions  - 

•  The  world  has  changed  .... 

-  Operational  demands  are  up,  not  down 

-  Investment  and  O&S  accounts  likely  to  remain  at  reduced  levels 

-  Changes  in  industrial  base  are  leaving  DoDbehind 

•  DoD  can  neither  Equip,  Train,  Support,  nor  Fight  in  this  new  world 
without  major  advances  in  Plug  &  Fight  capabilities 

•  OS  Process  is  no  panacea,  but  enduring  solutions  are  unlikely  without  it 

•  We  find  no  viable  or  practical  alternative 


OS  Process  is  critical  to 
future  warfighting  and  Title  10  responsibilities 


The  world  has  changed. 

Despite  the  fact  that  we  won  the  Cold  War,  today’s  operations  tempo  and  operational  demands  are  up,  not  down.  As  a 
consequence,  all  of  the  Services  are  facing  increasingly  severe  retention  problems.  Skilled  people  are  leaving  the 
Services  at  unacceptably  high  rates. 

O&M  accounts  are  likely  to  remain  at  reduced  levels,  despite  a  continuing  high  number  of  deployments  and  increased 
operations  tempo.  Without  substantial  changes  in  the  way  we  do  business,  this  problem  can  be  disastrous  in  the  near 
future. 

Changes  in  the  industrial  base  are  leaving  DoD  behind.  Many  suppliers  are  disincentivized  by  DoD’s  antique  processes 
and  by  the  shrinking  and  unique  market  it  represents.  At  one  time  DoD  could  dominate  technology  markets,  but  the 
explosion  in  non-military  technology  has  reduced  DoD  from  the  major  force  in  many  markets  to  a  bit  player  who  can 
safely  be  ignored.  Some  companies  have  abandoned  the  DoD  market,  and  will  only  sell  to  DoD  and  its  contractors  on  a 
standard  commercial  basis. 

For  these  and  many  other  reasons,  it  is  the  view  of  the  OSTF  that  DoD  can  neither  Equip,  Train,  Support,  nor  Fight  in 
this  new  world  without  major  advances  in  processes  which  will  provide  a  solid  foundation  for  developing  Plug  &  Fight 
capabilities. 

The  OS  Process  is  not  being  advanced  as  a  panacea  or  “silver  bullet”  for  these  problems;  rather,  the  OSTF  believes  that 
enduring  and  effective  solutions  are  unlikely  to  happen  unless  they  are  built  on  the  foundation  that  the  OS  Process 
provides. 

We  have  searched  for,  but  found  no  viable  or  practical  alternatives  to,  the  OS  Process  as  a  solution  to  these  problems. 
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Pilot  Open  Systems  Efforts 
Have  Produced  Impressive  Results 

•  Army  Intelligence  and  Electronic  Warfare  Common  Sensor  (IEWCS) 

-  Interchangeable  and  interoperable  common  modules;  VME  interface  standards 

-  Replaced  six  legacy  systems;  increased  interoperability;  reduced  development  &  production 
costs  by  40%,  R&D  time  by  64%,  EMD  time  by  29% 

•  Navy’s  New  Attack  Submarine  (NSSN) 

-  OS  Architecture  implemented  through  an  OS  IPT  &  Modular  Design 

-  2:1  reduction  in  development  time 

-  Greater  than  5:1  reduction  in  development  costs 

-  4:1  reduction  in  procurement  cost 

•  F-15,  F/A-18,  AV-8B  common  processor  pilot  programs 

-  Cross-program  modular  HW  &  SW  interfacing  with  legacy  platform  and  subsystems 

-  Expecting  about  50%  improvement  in  development  and  O&M  costs 

•  Seventh  Fleet  Command  Ship  (USS  Blue  Ridge) 

-  Converted  Mission  and  Housekeeping  functions  using  OS  Process  and  COTS 

-  Modified  ship  structure  to  enable  open,  rapid  reconfiguration 

7/13 Ml  » 


Several  pilot  OS  efforts  are  providing  very  encouraging  results.  These  initial  efforts  substantively  support  die  notion  that 
an  OS  Process  tailored  for  DoD,  as  both  a  technical  approach  and  a  preferred  business  strategy,  will  enable  superior 
combat  capability  fielded  more  quickly  and  affordably. 

Such  pilot  projects  include: 

(1)  The  Army’s  Intelligence  and  Electronic  Warfare  Common  Sensor  (IEWCS)  System,  which  replaced  six  separate 
and  unique  SIGINT/EW  legacy  systems,  each  having  little  commonality  of  hardware  or  software,  and  each  with  different 
operations,  support  personnel,  and  facilities.  The  systems  had  become  inadequate  and  unaffordable:  replacement  in  kind 
was  out  of  the  question.  The  systems  were  no  longer  viable  and  critical  batdefield  missions  were  endangered. 

The  Army  applied  the  concept  of  architecture-driven  modularity  at  the  PEO  level.  Interchangeable  and  interoperable 
common  hardware  and  software  modules,  mostly  COTS,  were  hosted  on  four  types  of  Army  and  Marine  tactical 
platforms.  Each  IEWCS  configuration  has  demonstrated  vastly  superior  technical  and  operational  performance 
capabilities.  Additionally,  the  IEWCS  development  demonstrated  significant  schedule  and  costs  improvements  relative 
to  traditional  Army  program  acquisition  programs:  R&D  time  improved  by  64%  (including  an  18-month  schedule 
slippage  needed  to  initiate  the  OS  Process)  and  EMD  time  by  29%.  As  a  result  of  implementing  OS,  the  IEWCS  system 
achieved  $35M,  S680M,  and  S900M  cost  avoidance  in  R&D,  production,  and  O&S  respectively  for  the  Army  and 
Marines. 

Most  importantly,  a  robust,  affordable  mission  capability  is  now  being  fielded  and  is  much  demanded  by  the  appropriate 
CinCs.  Missions  were  saved. 
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(2)  Navy  Submarine  Combat  Control  and  C3I  systems.  The  predecessor  BSY-2  Combat  Control  System  and 
some  C3I  systems  had  become  unaffordable,  jeopardizing  a  critical  mission.  An  OS  architecture  and  COTS  OS- 
compliant  components  were  used  to  develop  a  much  more  effective  and  affordable  alternative  for  the  New  Attack 
Submarine  (NSSN)  and  other  submarine  programs.  The  C3I  component  development  time  is  less  than  50%  of  that 
required  by  its  predecessor  BSY-2.  The  signal  processors  have  25  times  the  capacity  of  the  BSY-2,  and  the  data 
processors  57  times  die  capability  of  the  BSY-2.  Yet,  development  costs  are  approximately  18%  and  shipset  costs 
are  approximately  22%  relative  to  comparable  BSY-2  system  costs.  Again,  a  robust  mission  solution  is  fielded  in  a 
severe  budget  environment. 

(3)  F-15,  F/A-18,  and  AV-8B  common  software  and  processor  upgrade.  Addressing  long-term  weapon  system 
viability,  the  prime  contractor  is  applying  an  OS-based  implementation  across  three  very  dissimilar  aircraft  from 
three  different  Services.  Rehosting  legacy  code,  common  algorithms,  and  software  modules  were  developed  which 
could  be  executed  on  different  hardware,  and  were  successfully  flown  on  all  three  target  aircraft  interfacing  with 
disparate  “generations-old”  legacy  subsystems.  Common  processors  are  being  developed  under  parallel  programs, 
again  interfacing  with  myriad  legacy  subsystems  while  providing  significantly  increased  throughput  and  memory. 
These  improvements  will  accommodate  software  upgrades  to  high-order  language  and  object-oriented  design  as 
well  as  provide  for  increased  functionality  in  the  future.  The  use  of  Open  standards  and  commercial  parts  results  in 
unit  prices  that  are  roughly  half  the  cost  of  the  legacy  computers  and  eases  the  incorporation  of  new  technology  as 
it  evolves. 

(4)  Recent  upgrades  to  the  mission  and  housekeeping  functions  for  the  Seventh  Fleet  command  ship,  the  USS  Blue 
Ridge  (LCC-19),  have  used  OS  and  COTS  components  extensively.  The  OS-based  implementation  will  provide 
not  only  significant  technical  advantage,  but  will  enable  U.S.  warfighters  to  innovate  on  the  spot,  permitting 
dynamic  functional  adaptations  in  support  of  fleet  operations.  Such  Plug  &  Fight  and  Plug  &  Play  modifications, 
using  OS  architecture  and  components,  permits  more  flexible  and  rapid  reconfiguration  to  meet  future  fleet 
warfighting  requirements.  For  example,  in  the  first  ever  Air  Force  preparation  of  an  Air  Tasking  Order  aboard 
ship,  13th  Air  Force  prepared  the  daily  ATO  aboard  Blue  Ridge  in  support  of  the  10,000  man,  300  aircraft  Tandem 
Thrust  exercise  with  Australia.  Perhaps  most  importantly,  this  modernization  was  largely  accomplished  by  the  staff 
and  crew  of  Blue  Ridge,  an  example  of  OS  enabling  the  innovative  prowess  of  the  individual  U.S.  warrior. 
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The  Vision 


Enabling  DoD  to  affordably  configure  and 
integrate  Forces,  systems,  and  processes  for 
high  combat  effectiveness  and  life-long  viability 
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Meeting  the  challenges  identified  in  the  Why  We  Care  section  requires  that  our  forces  be  agile,  our  systems  adaptable, 
and  that  all  investment  be  configured  wisely  for  maximum  economy,  reuse  of  investment,  and  continuing  technology 
refresh.  The  ability  to  readily  integrate  as  needed,  at  the  moment,  at  all  levels  —  from  forces  to  systems  to  components 
--  is  rapidly  becoming  a  critical  DoD  need. 

Smart  modularity  of  forces,  systems,  and  management  processes  is  necessary  to  meet  this  need.  The  techniques  for 
achieving  such  modularity  are  within  the  grasp  of  DoD  and  can  be  realized  through  an  OS  Process  such  as 
recommended  by  the  OSTF. 

This  is  our  vision: 

•  That  DoD  energetically  embrace  an  OS  Process  of  some  sort  and  launch  an  aggressive  program  throughout  all  DoD 
entities  to  reconfigure  the  very  fabric  of  DoD;  that  an  OS  Process  become  an  ubiquitous  core  value  and  mindset. 

•  That  in  achieving  OS  attributes,  DoD  will  realize  a  quantum  improvement  in  force  effectiveness  and  use  of  our 
critical  resources. 

•  More  specifically,  Plug  &  Fight/Play  capability  will: 

•  Improve  the  ability  of  DoD  to  rapidly  and  effectively  respond  to  the  new  threats  from  die  outside  that  demand 
quick  and  effective  reaction  by  joint  U.S.  and  allied  forces. 

•  Enhance  DoD  capability  to  create  flexible  systems  and  forces  by  effectively  exploiting  the  opportunities 
provided  by  the  commercial  market  place  and  new  technologies,  and  keep  these  systems  viable  through  their 
desired  life  times. 

•  Create  an  effective  approach  to  adapt  to  the  new  business  and  engineering  methods  within  DoD. 

•  Increase  the  DoD  and  Services’  ability  to  realize  J V  2010  vision. 

•  Enhance  interoperability  and  affordability  via  Practical  Openness. 
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Critical  Open  Systems  Lessons  Learned  for  DoD 


The  Nuggets 

(1)  Configure  Forces,  systems  and  processes  for  continuous  viability 

(2)  Achieve  architecture-driven  modularity 

(3)  Manage  to  the  natural  cycle  rates  of  underlying  components 

•  U.S.  Forces,  systems,  and  processes  severely  threatened  by  their  lack  of  agility  in  dynamic  world 

•  For  systems,  today’s  threat  domains  include  not  only  combat  capability  but  also  inadequate 
affordability,  response  time,  sustainment,  eroding  supplier  base 

Must  configure  for  constant  evolution  in  a  dynamic  world 

•  Our  Forces  and  systems  must  be  rich  in  “smart”  modularity,  driven  by  architecture,  and  configured 
as  a  hierarchy  of  modular  “sockets”  enabling  adaptation  in  a  dynamic  world 

•  Must  revamp  our  management  processes  to  encourage  and  leverage  the  natural  cycle  rates  of  the 
underlying  components 


The  primary  benefit  of  the  OS  experience  for  DoD 
is  not  so  much  about  mandating  pure  “Open”  solutions  as  it  is  about 
extensive,  wise  modularity  and  a  significantly  enlightened  management  approach 
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Militaries  are  prepared  to  fight  either  the  last  war  or  the  war  of  their  leaders’  youth.  Fundamental  change  requires 
either  a  disaster  or  a  period  of  about  two  military  careers.  Today,  the  natural  cycle  rate  of  technology  change  occurs 
within  the  tour  of  duty  of  a  military  officer  —  never  mind  over  the  entire  career.  Today,  we  seeing  a  Mean-Time-to- 
Obsolescence  that  is  shorter  than  the  Mean-Time-to-Failure.  DoD  forces,  systems,  and  processes  suffer  greatly  from 
an  inability  to  keep  up. 

Examining  the  OS  experience,  the  OSTF  identified  three  critical  concepts  for  DoD: 

•  The  need  to  focus  upon  continuous  viability  as  a  critical  attribute.  Ironically,  today’s  systems  are  primarily 
falling  prey  to  unaffordability,  sustainment  problems,  incompatibility  with  the  force,  obsolescence,  and  eroding 
supplier  bases.  Just  as  robustness  against  the  enemy  threat  is  a  critical  system  criteria,  so  must  be  the  continuing 
viability  of  the  system  in  the  realities  of  today’s  world. 

•  Extensive  architecturally-driven  modularity  is  requisite  for  needed  agility,  ability  to  reconstitute  and  integrate 
as  needed,  commercial  economies  and  reuse,  and  technology  refresh  to  maintain  compatibility  and  supplier 
bases. 

•  Today  the  world  is  change  and  DoD  needs  management  processes  which  enable  change  as  an  essential 
attribute  rather  than  as  an  evil  to  be  resisted.  Much  of  DoD’ s  acquisition,  support,  and  oversight  philosophy  is 
now  dysfunctional  and  needs  revamping. 

Note  that  the  OSTF  does  not  endorse  a  pell  mell  rush  to  pure  Open  solutions.  There  is  a  great  heed  for  rigorous 
controlled  modularity,  but  we  observe  that  in  the  rest  of  our  lives  the  best  available  solution  is  often  not  the  most 
pure  solution.  We  are  therefore  putting  the  greatest  emphasis  on  developing  high  integrity  techniques  for  identifying 
the  most  optimum  solution  rather  than  mandating  a  particular  outcome. 
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Analyzing  and  Addressing  Viability  Risk 

-  A  Strawman  Approach  - 

The  fact  of  program-threatening  evolution  is  absolutely  certain  — 

Need  to  develop  explicit  risk  mitigation  strategies 

Step  1:  Risk  Analysis:  Characterize  expected  evolution  and  cycle-rate  of  the  key  factors 
affecting  viability  throughout  the  life  of  the  product 

-  Likely  topics  include:  affordability,  technology,  subsystem  characteristics,  external  interfaces, 
requirements,  supplier  base 

-  (Attributes  for  life-long  viability  probably  needed  just  to  get  through  EMD  -  witness  F-22) 
Step  2:  Apply  Plug  &  Fight/Plug  &  Play/Openness  as  critical  attributes 

-  Example  program  tasks:  concept  development,  analysis  of  alternative,  acquisition  strategy, 
tailored  program  management  scheme 

-  Example  OS  topics:  continuing  affordability,  evolving  connectivity,  tech  refresh,  suppliers 

Step  3:  Demonstrate  that  architecture  gets  best  life-long  viability  within  available 
resources 

Step  4:  Include  OS  Process  in  all  relevant  procurement  matters 

-  e.g.,  Requirements,  specifications,  Source  Selection  Criteria,  etc. 

Make  sound  life-long  viability  a  mandatory  milestone  review  item  | 
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Long-term  viability  should  be  a  critical  system  attribute  and  subject  to  mandatory  acute  Management  and  Milestone 
Review  attention.  There  is  a  logical  sequence  for  approaching  this  need: 

1.  Identify  the  key  factors  affecting  the  system’s  life-long  viability  and  characterize  their  expected  evolution  and 
cycle-rate.  The  list  of  key  factors  will  probably  include  the  topics  listed  above.  Estimating  future  evolution  is 
difficult,  but  an  approximately  correct  answer  is  much  better  than  what  we  do  today.  In  most  cases,  the  fact  of 
rapid  change  is  certain  but  the  details  of  future  solutions  are  unknown  at  the  time.  The  life-long  viability  of  the 
system  architecture  and  the  program  management  structure  in  the  face  of  such  uncertainty  is  a  critical  system 
criteria.  The  estimate  of  the  direction  and  rapidity  of  the  evolution  is  used  to  test  this  life-long  viability. 

2.  Analyze  the  degree  of  Plug  &  Fight,  Plug  &  Play,  and  Openness  which  will  provide  the  best  life-long  viability  for 
the  resources  available.  The  result  should  be  reflected  throughout  the  system  and  management  documentation, 
including  such  documents  as  listed  above. 

3.  Demonstrate  that  the  system  architecture  and  standards  best  achieve  the  Openness  requirements  developed  above 
(2).  Legacy  systems  present  a  different  challenge  in  that  there  is  an  existing  system  architecture  to  contend  with. 
This  existing  architecture  may  not  easily  facilitate  migration  to  a  more  open  architecture.  In  some  instances,  such 
as  legacy  systems  with  very  limited  remaining  operational  utility,  the  best  decision  may  be  not  to  migrate  the 
system  to  an  Open  system.  An  appropriate  Open  Systems  migration  plan  must  be  established  for  each  legacy 
system  with  viable  future  operational  utility. 

4.  Include  the  OS  Process  and  the  Openness  requirements  in  all  applicable  acquisition  actions,  and  particularly  as  a 
source  selection  criteria. 

The  above  should  be  a  mandatory  OSD,  JCS,  and  Service  Milestone  Review  topic. 
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Architecture  Driven  Modularity 

Capturing  the  benefits  of  Plug  &  Fight,  Plug  &  Play,  and  Commercial  OS 
requires  a  hierarchy  of  architectures 

Hierarchy  of  Architectures 


Axioms 

•  Plug  &  Fight,  Plug  &  Play,  and  Open  components  are  related  but  different 

•  Each  must  be  individually  nurtured,  but  in  a  coordinated,  mutually  supportive  approach 

•  Each  must  impose  only  the  minimum  essential  requirements,  or  they  will  stifle  the  others 

•  Ops,  Tech,  and  Sys  Architectures  each  have  different  sponsors,  as  does  each  tier  of  the  hierarchy 

•  Forces  and  systems  must  be  simultaneously  compatible  with  all  relevant  architectures  in  the  hierarchy 
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A  hierarchy  of  architectures  and  related  bodies  of  standards. 

Many  tiers  of  DoD  have  legitimate  needs  which  will  soon  lead  to  architectures.  For  example,  JCS  is  starting  to  explore 
interoperability  needed  for  warfighting  and  is  currently  addressing  some  aspects  of  C4ISR  interoperability.  Presumably, 
in  the  fixture  we  will  see  joint  technical  architectures  for  interoperability  of  functions  like  mission  planning,  logistics 
viability  and  management  systems,  deployment,  modeling  &  simulation,  and  administration. 

At  the  System-of-Systems  tier  there  are  a  number  of  areas  like  Theater  Air  &  Missile  Defense  with  the  Single  Integrated 
Air  Picture  which  will  result  in  mission-wide  architectures.  The  Army  IEWCS  is  a  good  example  of  a  PEO 
constructively  imposing  a  cross-system  architecture.  We  can  expect  more  cross-system  architectures  to  be  imposed  by 
intermediate  tiers  (e.g.  the  Joint  Logistics  Commanders,  or  a  Service  Assistant  Chief-of-Staff  for  Logistics).  There  are 
“building  code”  architectures  needed  for  acquisition  efficiencies  as  well  as  operational  needs. 

The  OSTF  foresees  a  world  in  the  near  future  of  inter-related  architectures  in  a  hierarchical  construct.  The  architectures 
and  their  associated  bodies  of  standards  will  be  dynamic  and  provide  another  source  of  rapid  change  with  which 
individual  weapons  systems  and  the  supporting  processes  must  cope. 

Indeed,  the  hierarchy  includes  the  weapons  system  tier  which  hopefully  will  be  configured  as  a  structure  of  F3I  “sockets” 
to  allow  lower  level  tiers  (primes,  subsystems,  and  component  suppliers)  maximum  flexibility  to  deal  adequately  and 
affordably  with  demands  on  the  weapons  system  and  the  dynamics  of  the  commercially  oriented  industrial  base.  The 
industrial  base  will  operate  with  their  hierarchy  of  architectures  and  associated  standards. 

It  is  hard  to  imagine  that  DoD  will  be  able  to  function  constructively  in  the  new,  highly  dynamic  world  without  such  a 
hierarchy  of  disciplined  architectures. 

Hierarchical  constructs 

The  figures  above  suggest  several  useful  ways  of  considering  the  hierarchy  for  various  purposes. 
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The  “stack  of  umbrellas”  illustrates  that  many  functional  tiers  within  DoD  have  legitimate  architectural  requirements. 
These  may  result  in  a  unique  “horizontal”  architectures  (an  “umbrella”),  or  they  may  be  included  in  part  in  various 
“vertical”  architectures. 

OSD  and  JCS  have  define  three  architectural  domains:  Operational,  System,  and  Technical.  These  are  referred  to  here 
as  “vertical”  architectures  and,  for  reference,  mapped  on  the  figure  as  vertical  lines  showing  the  organizational  tiers 
most  affected.  Each  of  these  architectures  have  their  own  sponsors,  Operational  Architectures  being  primarily  the 
purview  of  the  JCS  and  service  operational  communities,  System  Architectures  being  primarily  the  purview  of  the 
OSD/Service  acquisition  community,  and  Technical  Architectures  being  a  combined  operational  and  acquisition 
concern. 

The  critical  DoD  interest  in  OS  is  to  simultaneously  capture  the  benefits  of  Plug  &  Fight,  Plug  &  Play,  and  economic 
commercial  components. 

Plug  &  Fight  means  ready  integratability  and  interoperability  throughout  the  Forces.  This  can  be  achieved  only  with  a 
top-down,  force-wide  architecture  and  the  compliance  of  every  related  element  in  the  force.  The  architecture  must 
reference  a  body  of  standards  which  are  truly  interoperable.  In  this  regard,  the  Joint  Technical  Architecture  is 
currently  flawed.  In  an  effort  to  accommodate  the  constrains  of  legacy  systems  and  Title  10  prerogatives,  the  JTA  is  a 
collection  of  standards  which  are  perhaps  individually  meritorious  but  which  are  not  necessarily  mutually 
interoperable.  Thus,  systems  can  be  totally  compliant  with  the  JTA  and  not  be  interoperable. 

The  JTA  is  not  currently  an  architecture  assuring  joint  interoperability.  OSD  and  JCS  need  to  mandate  and  enforce  a 
single  interoperable  body  of  standards. 

Complex  functions  may  not  be  amenable  to  precision  interoperability  solely  by  standards.  The  inevitable  differences 
in  interpreting  and  implementing  key  standards  may  thwart  the  needed  interoperability.  In  these  cases  it  may  be 
necessary  to  require  universal  use  of  a  common  kernel  or  processor. 

Plug  &  Play  resides  in  the  middle  tiers  and  is  the  system  attribute  which  strives  to  simultaneously  enable  dynamic 
flow-down  for  integratability  and  bubble-up  of  commercial  economies.  Plug  &  Play  is  enabled  when  a  system  is 
configured  as  a  structure  of  F3I  “sockets”  permitting  underlying  components  to  cycle  asynchronously  at  their  natural 
rates.  Basic  architectural  elements  and  F3I  sockets  also  have  finite  lives  and  obsolescence  and  the  system  must  be 
configured  to  enable  graceful  evolution. 

It  is  vital  to  study  carefully  how  each  attribute  is  achieved  in  the  hierarchies,  for  attention  is  needed  to  assure  that  the 
benefits  of  Plug  &  Fight,  Plug  &  Play,  and  economies  of  Open  components  are  simultaneously  realized.  Without 
disciplined  attention  to  the  full  perspective,  it  is  almost  certain  that  local  optimizations  will  compromise  the  overall 
structure. 

At  the  lowest  tier,  DoD  desperately  needs  to  capture  the  enormous  benefits  of  commercial  components  with  their  large 
industrial  investments  and  economies  of  scale.  The  greater  this  class  of  benefit,  generally  the  less  influence  DoD  has 
over  the  product  and  related  standards.  And  these  standards  themselves  have  finite  lives  and  looming  obsolescence. 

There  exist  certain  axioms  which  apply  across  the  widely  disparate  tiers  of  the  hierarchy. 

Every  entity  must  be  configured  in  the  context  of  an  overall  architecture  and  that  architecture  should  be  constrained  by 
all  the  architectures  which  affect  it,  including  both  higher  tier  and  lower  tier  architectures. 

It  is  not  enough  that  each  component  is  individually  Open:  the  whole  must  be  as  Open  as  practical  and  all  components 
must  integrate  well  together  and  evolve  gracefully,  maintaining  Openness  over  the  life  of  the  entity. 

To  this  end,  each  tier  must  rigorously  impose  only  the  absolute  minimum  constraints  necessary  to  achieve  its 
legitimate  requirements.  To  the  full  extent  practical,  only  functional  constraints  should  be  imposed,  leaving  the 
detailed  how  to  the  lowest  levels. 
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Partitioning  for  Modularity 

Good  modularity  demands  robust  isolation  of  constituent  elements, 
connected  only  through  interoperable  interface  specifications 


-  Element  substitution  and  renewal 

-  Reuse  and  resource  sharing 

-  Ready  modernization  and  growth 


Design  attributes: 

-  Modularity 

-  Portability 

-  Scalability 
How  much? 

-  System-of-systems  needs 

-  Operability  and  interoperability 

-  Commonality  (horizontal,  vertical,  across  functions) 

Decomposing  the  system 

-  Emphasize  open  partitioning,  leverage  standards,  get  expert  advice 

-  Need  hard  isolation  of  modules,  interact  only  through  interface  specs 
Implementation 

-  Designated  system-of-systems  and  system  architects 

-  Mechanisms  to  assure  local  decisions  don’t  compromise  system  design 

-  Test  attributes  sought 

-  Tight  discipline  throughout  life  cycle;  don’t  let  attributes  dissipate 


Attributes  often  compete  —  for  example: 

•  MS  Windows  gives  broad  commonality 
but  poor  interoperability  and  reliability 

•  Apple  gives  interoperability  and 
reliability  but  limited  commonality 
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An  OS  requires,  as  a  minimum,  an  architecture  with  modularity,  portability,  and  scaleable  attributes.  Interoperability  is 
frequently  defined  as  a  Plug  &  Play  capability  that  is  realized  when  system  components  are  shared  among  unanticipated 
users  and  in  a  variety  of  environments.  Maintainability  implies  a  capability  to  repair  and  extend  functionality  so  the 
system  capabilities  can  grow  beyond  initial  implementation.  However,  these  Plug  &  Play  attributes  often  compete  so  that 
it  is  difficult  to  develop  a  design  that  maximizes  desired  system  attributes.  For  example,  Microsoft’s  Windows  95  is 
widely  used  but  has  well  known  reliability  problems  and  does  not  interoperate  well  with  non-Windows  products.  In 
contrast,  Apple’s  Macintosh  computers  are  known  for  their  interoperability  but  are  less  widely  used. 

Although  there  is  much  emphasis  in  the  use  of  standards  and  application  interfaces,  architectural  decomposition  also  plays 
a  significant  role  in  achieving  OS  requirements.  For  example,  command  and  control  system  functions  overlap  with 
intelligence  systems  and  systems  within  the  command  and  control  system  domain  overlap  with  each  other.  Therefore, 
different  system  decompositions  may  promote  Openness  with  one  system  over  another. 

System-of-system  and  system  architects  are  needed  at  each  level  to  ensure  the  best  overall  design  and  to  guard  against 
PM’s  locally  optimizing  their  system  design  at  the  expense  of  other  levels  in  the  architectural  hierarchy.  Furthermore, 
system  testing  should  include  system  attribute  evaluations  and  tighter  discipline  is  needed  throughout  the  life  cycle  so  that 
OS  attributes  don’t  dissipate. 

Such  an  approach  fosters  families  of  modular  systems  and  products  which  can  then  be  tailored  to  meet  specific  warfighter 
needs. 
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DoD  Already  Understands  the  Basics 

-  Similar  to  Architecting  for  Software  Development  - 

•  OS  Process  in  DoD  today  is  analogous  to  software  development  20  years  ago 

-  Was  art,  now  art  +  discipline  with  axioms,  institutions  (e.g.  SEI),  and  milestone  exit  criteria 

Very  good  architecting  is  as  essential  for  good  modularity  as  forSW  development  — 

A  flawed  architecture  compromises  all  that  follows 

•  Key  outputs  are  overall  structure,  partitioning,  and  interface  standards 

•  The  basics  are  at  hand  and  already  understood  —  it’s  mostly  a  matter  of  doing  it 

•  Systems  architecting  is  a  discipline  of  balancing  dissimilar  requirements  such  as  CONOPS, 
schedule,  performance,  risk,  supportability,  reliability,  and  cost,  according  to  the  customer’s 
relative  priorities 

•  Only  one  or  two  attributes  usually  can  be  constrained,  but  good  architecture  optimizes  the  mix 

•  The  architecture  needs  to  follow  Open  principles,  even  if  the  parts  are  less  than  Open 

•  But  even  if  parts  not  Open,  must  follow  the  OS  Process  tenants,  or  product  will  almost  certainly  be 
monstrous  to  employ  and  sustain 


Axiom 

Architecture-driven  modularity  is  requisite  to  achieving  OS  attributes  - 
therefore,  OS  Process  should  be  a  mandatory  and  non-negotiable  discipline 
for  all  activities  configuring  Forces,  systems,  and  processes 


Although  not  an  established  discipline,  the  notions  of  an  OS  Process  are  understood.  Much  like  software  engineering 
two  decades  ago,  the  principles  are  under  development  and  examples  exist.  The  underlying  principles  need  to  be 
articulated  and  supported  by  appropriate  training. 

Success  depends  on  establishing  the  architectural  underpinnings.  The  attributes  of  Plug  &  Play  must  be  planned 
during  the  architecting  process.  A  key  component  of  this  process  is  partitioning  into  components  and  the  definition 
of  die  interfaces  to  those  components.  While  there  are  principles  to  be  applied  during  the  process,  it  is  a  matter  of 
balancing  a  variety  of  requirements  and  desired  attributes  of  the  system.  Considerable  judgment  is  needed,  based  on 
an  understanding  not  only  of  the  domain  but  of  the  available  standards  and  products  and  their  interaction. 

Industry  can  provide  considerable  experience  in  implementing  an  effective  OS  Process. 

Although  this  may  be  viewed  as  a  one-pass,  top-down  process,  in  practice  it  is  iterative.  Decisions  made  at  one  level 
constrain  the  choices  at  the  next  level.  When  faced  with  those  constraints  at  the  next  level,  the  architect  may 
discover  that  the  available  choices  preclude  an  important  priority  and  will  revisit  an  earlier  decision. 
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Developing  and  Sustaining  a  Hierarchy  of  Architectures 

-  Some  Institutional  Imperatives  - 

•  We  have  all  been  scared  by  blanket  imposition  of  well-intended  causes  de  jour 

•  While  desired  outcomes  and  constraints  can  be  mandated,  detailed  solutions  should  be 
collaborative  amongst  the  stakeholders  (and  be  prepared  to  motivate  intransigent 
stakeholder.) 

•  Achieving  a  widespread  DoD  OS  Process  will  require  aggressive  championing,  but 
anointed  “do  it  my  way”  czars  will  be  successfully  resisted  at  all  levels 

•  Through  Acquisition  Reform,  DoD  digging  out  from  under  the  regulatory  heap  that 
was  burying  it 

•  Need  for  OS  Process  become  a  mindset  and  core  value,  not  another  massive 

bureaucracy _ 

Axioms 

•  Only  the  vital,  bare  minimum  constraints  needed  to  do  the  job  should  be 
imposed,  and  at  the  highest  functional  and  organizational  tiers  practical 
■  Our  performance-based  acquisition  should  also  be  our  OS  Process: 

-  Higher  tiers  identify  needed  outcomes  and  assure  high  integrity  processes 

-  Stakeholders  in  the  solution  devise  the  hotv 


DoD  has  over  the  years  implemented  many  initiatives  that  had  a  well  reasoned  basis,  both  from  a  technology  and  a 
business  perspective.  Unfortunately,  too  often  these  initiatives  have  been  implemented  by  the  bureaucracy  through  the 
imposition  of  rules  that  were  blindly  administered.  As  a  result,  the  program  management  community  has  built  an 
effective  resistance  to  such  initiatives. 

While  it  is  often  effective  to  have  an  advocate  for  a  specific  initiative,  the  appointment  of  a  czar  for  OS  will 
undoubtedly  energize  that  resistance. 

To  be  effective,  the  OS  Process  and  the  supporting  concepts  must  become  part  of  the  DoD  institutional  processes.  It 
must  be  part  of  the  line  management. 

The  architectural  constraints  placed  on  systems  must  be  developed  at  each  level  and  supported  by  line  management  at 
those  levels.  The  application  of  these  architectural  constraints  must  be  understood  by  everyone  to  be  in  the  best 
interest  of  the  organization  from  a  system-of-systems  perspective. 

In  applying  these  constraints,  it  is  important  that  only  those  constraints  that  are  essential  for  accomplishing  the  mission 
and  goals  of  a  particular  tier  be  imposed.  There  must  be  strong  resistance  to  the  imposition  of  unnecessary  constraints. 

Fortunately,  the  performance-based  acquisition  approach  provides  the  mechanism  for  implementing  the  OS  Process. 
Higher  levels  define  the  needed  outcomes  and  ensure  quality  processes  and  the  stakeholder  levels  define  the  how. 
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Requirements  and 
Resources 


Administering  an  OS  Architecture 

-  Generic  OS  Process  Model  - 
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For  the  practical  administration  of  an  OS  architecture  the  OSTF  suggests  an  adaptation  of  the  widely  understood 
Configuration  Control  Board  (CCB)  used  by  Program  Management  offices  for  decades.  Adaptation  to  an  Architectural 
Control  Board  (ACB)  is  illustrated  in  the  generic  model  which  illustrates  the  first  order  principles  which  would  apply  to 
all  tiers  of  the  architectural  hierarchy.  The  slides  following  this  suggest  application  of  the  generic  model  to  several  tiers 
in  the  architectural  hierarchy. 

The  OS  process  works  within  the  existing  roles  and  missions  within  DoD.  The  ACB  advises  existing  Line  Authority  just 
as  CCB  supports  a  Program  Director.  The  Line  Authority  responsible  for  each  architecture  oversees  die  process,  receives 
and  allocates  requirements,  responsibilities,  authorities,  and  resources  to  system  producers.  The  ACB  is  a  review  board 
which  considers  and  advises  on  proposed  actions  related  to  architecture  and  compliance.  A  Systems  Engineering 
function  collaborates  with  various  stakeholders  in  the  solution  to  develop  and  maintain  the  needed  architecture  and  body 
of  interface  standards,  and  brings  their  products  to  the  ACB  for  scrutiny  and  endorsement  on  the  way  to  the  Line 
Authority  for  approval  and  imposition  on  lower  tiers.  Systems  and  processes  subject  to  the  architecture  demonstrate 
compliance  to  the  ACB  and  obtain  endorsement  as  a  mandatory  exit  criteria  to  milestone  reviews.  All  waiver  requests 
pass  through  the  ACB  for  a  recommendation  on  their  way  to  the  Line  Authority  for  approval. 

The  ACB  would  typically  be  chaired  by  the  Line  Authority(s)  responsible  for  the  subject  architecture.  Board  members 
would  be  the  relevant  functional  directors  supporting  the  Line  Authority. 

Technical  support  is  provided  by  a  System  Architect  serving  in  the  interest  of  the  Line  Authority.  System  architecting  is 
a  function  of  Systems  Engineering,  organizing  and  shepherding  the  collaborative  efforts  of  the  various  stakeholders  to 
develop  a  responsive  architecture.  While  the  various  stakeholders  have  access  to  the  ACB  and  the  Line  Authority  though 
whatever  channels  connect  them  with  the  developing  architecture,  the  System  Architect  has  a  substantial  power  base  as 
the  primary  technical  advisor  to  the  ACB  chairperson,  the  Line  Authority.  It  is  essential  that  the  System  Architect 
possess  substantial  experience  and  educational  credentials  and  understand  the  needs  of  the  Line  Authority  and  the  various 
stakeholders.  With  system  architecting  being  a  function  of  quality  system  engineering,  the  System  Architect  must  be 
supported  by  a  competent  System  Engineering  organization  which  also  acts  in  the  best  interest  of  the  Line  Authority  and 
is  competent  and  well  informed. 
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There  is  a  strong  preference  that  the  architecture  and  corpus  of  interface  standards  be  developed  and  maintained  in  a 
collaborative  process  with  the  various  stakeholders  in  the  structure  of  the  solutions.  Often  the  expertise  needed  to 
develop  the  overall  architecture  is  different  than  that  needed  to  establish  detailed  interface  specification,  and  separate 
bodies  may  be  expected. 

Compliance  should  be  an  exit  criteria  for  all  milestone  reviews  of  the  subject  systems  and  processes.  That  is  to  say, 
ACB  endorsement  would  be  requisite  for  the  milestone  review  to  convene.  It  will  sometimes  be  the  case  that 
exceptions  to  aspects  of  the  interface  standards  will  be  in  the  best  interest  of  the  government.  A  waiver  process  is 
required,  which  would  include  ACB  review  and  endorsement.  Waivers  are  to  be  expected  and  should  not  be  treated 
with  prejudice,  but  the  purpose  of  architectures  is  to  achieve  higher  level  objectives  not  addressed  at  lower  levels: 
requesting  a  wavier  should  require  a  strong  burden  of  proof  demonstrating  that  the  waiver  is  clearly  in  the  best  interest 
of  the  government  as  seen  from  all  of  the  relevant  perspectives. 
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Force  Level  Interoperability 

-  An  OSD/JCS  System-of- Systems  Application  - 
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Interoperability  is  a  high  order  need,  demanding  DoD-wide  architectures  for  each  of  several  domains  (e.g.  C4ISR, 
mission  planning,  logistics  management),  which  only  can  be  enforced  at  the  OSD/JCS  level.  Using  the  C4ISR  domain 
as  an  example,  the  Line  Authorities  would  be  the  USD(A&T),  ASD(C3I),  and  VC  JSC.  A  subject  architecture  would 
be  the  Joint  Technical  Architecture  (which  is  not  really  a  systems  architecture  at  all,  but  rather  a  corpus  of  interface 
standards).  The  existing  Architecture  Control  Council  (ACC),  co-chaired  by  USD(A&T),  ASD(C3I),  and  JS/J-6, 
could  serve  as  the  JTA  ACB.  Producers  are  primarily  PEOs  and  PMs. 

The  System  Architect  might  be  the  DDTSE&E,  with  system  engineering  technical  support.  Stakeholders  include 
elements  of  the  JCS  and  Service  users,  producers,  funders,  and  sustainers.  Collaborative  organizations  include  the 
Technical  Architecture  Steering  Group  (TASG)  and  the  Joint  Technical  Architecture  Working  Group  (JTAWG). 

In  operation,  maintenance,  and  revision  proposals,  requests  for  waivers  bubble  up  from  stakeholder  groups  and 
producers  and  are  evaluated  by  the  system  architect,  supported  by  the  system  engineering  organization. 
Recommendations  are  made  to  the  formal  ACB,  which  considers  the  proposal  from  the  perspective  of  the  various 
member  disciplines  and  which  in  turn  advises  the  Line  Authorities.  The  Line  Authorities  hold  the  final  approval 
authority. 
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Single  Integrated  Air  Picture 

-  An  Emerging  Joint  System-of-Systems  Application  - 
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An  example  of  an  emerging  domain  architecture  is  the  Single  Integrated  Air  Picture  (SLAP),  a  component  of  Theater 
Air  &  Missile  Defense.  The  SLAP  will  depend  upon  systems  and  networking  largely  owned,  justified,  and  funded  by 
the  services  for  other  purposes.  Many  of  the  organizational  functions  necessary  to  implement  a  SLAP  are  not  yet 
established.  It  appears  that  the  Line  Authority  for  implementation  of  the  SLAP  will  be  the  Director  of  the  Ballistic 
Missile  Defense  Organization  at  the  systems  command  level.  An  ACE  function  has  not  yet  been  assigned  to  a 
particular  entity.  The  systems  engineering  function  will  be  assigned  to  a  systems  engineering  advisory  group. 
Stakeholder  interests  are  being  addressed  by  the  JTAMD  Working  Integrated  Product  Teams  (WLPTs).  The 
documents  produced  by  the  WIPTs  are  to  be  consistent  with  the  JTA  and  C4ISP  Architecture  Framework.  It  is 
anticipated  that  the  system  architect  will  probably  be  located  within  the  BMDO  organization 

In  the  end,  a  sound  engineering  solution  requires  that  the  systems  architect  be  a  single,  actual  person.  In  addition  to 
providing  the  architect  function,  the  architect  will  certify  to  the  ACB  that  the  proposed  systems  architecture  design 
will  meet  the  requirements,  including  Plug  &  Fight/Play,  given  the  known  constraints.  The  architect  must  possess 
both  the  experience  and  educational  credentials  to  be  able  to  asses  the  proposed  architecture  and  understand  how  it  fits 
into  the  larger  picture,  and  does  not  merely  meet  a  narrow  range  of  requirements. 
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Weapons  System  Level  Application 
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At  the  major  weapons  system  level,  the  Line  Authority  is  the  Program  Manager,  responsible  for  the  system  level 
architecture.  At  the  system  level,  architectural  objectives  are  the  required  functioning  of  the  system,  enabling  Plug  & 
Play  to  maintain  system  viability  and  flexibility,  compatibility  with  high-tier  architectures  to  enable  Plug  &  Fight,  and 
minimizing  any  constraints  on  lower  tiers  which  might  restrict  the  economies  of  COTS  and  transparent  technology 
refresh  by  subcontractors  and  suppliers. 

The  Program  Office  ACB  is  probably  chaired  by  the  Program  Manager  and  is  an  additional  role  for  members  of  the 
CCB.  The  system  architect  may  be  the  system  engineer  and  is  supported  by  the  system  engineering  organization. 

The  prime  contractor  and  key  subcontractors  maintain  analogous  structures  with  similar  objectives  of  meeting 
program  requirements  while  leaving  suppliers  maximum  opportunity  to  keep  the  system  refreshed  at  the  assembly  and 
component  level. 

If  each  lower  level  is  producing  a  system,  as  opposed  to  a  component,  then  a  systems  architect  would  be  necessary  for 
certification  of  that  design  to  the  next  higher  level.  At  some  lower  level,  however,  the  next  level  up  might  elect  to  rely 
instead  on  the  producer’s  published  specifications  or  the  self-certification  of  the  producer. 

Each  weapon  system  tier  is  decoupled  through  the  use  of  functional  specifications,  F3I  interfaces,  and  migration  plans, 
permitting  each  element  to  cycle  at  its  own  natural  rate. 
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Standards  and  “Openness” 

•  Standards  define  the  inter-module  connections  (“sockets”)  which  enable  modularity 

•  “Open”  refers  to  use  of  interfaces  and  protocols  that  conform  to  well  defined,  widely  used, 
preferably  non-proprietary  standards.  Open  standards  are  those  developed  by  recognized  standards 
bodies  or  the  commercial  marketplace.  Standards  may  be: 

-  open  (or  public):  e.g.  tires,  electric  outlets,  some  GPS  data  formats 

-  owned:  e.g.  most  car  parts,  MS  Windows  95 

-  de  facto:  e.g.  8.5”  x  11”  paper,  typewriter  keyboard 

-  proprietary:  e.g.  most  weapons  systems  key  components 

•  The  level  of  Openness  refers  to  the  system  design  level  at  or  above  which  interfaces  conform  to 
Open  standards 

•  The  level  of  Openness  determines  the  extent  to  which  a  weapon  system  can: 

-  Use  multiple  suppliers  for  competitive  procurements  through  its  total  life  cycle 

-  Insert  new  hardware  and  software  technology  whenever  available 

-  Assign  the  control  of  design,  repair,  and  replacement  to  the  supplier 

•  An  “80%”  quick,  Open  solution  which  is  affordable  and  sustainable  is  usually  better  than  a 
functionally  ideal  solution  which  we  probably  can  neither  afford  nor  sustain 


Axiom 

Strongjiresunyrtioi^a^^ 


DoD  has  historically  approached  standards  the  way  it  approaches  MILSPECs  --  establish  them  and  expect  the  world 
to  comply.  But  that  often  misses  the  enormous  economies  of  private  investment  in  the  commercial  market.  As  a 
customer,  DoD  must  shop  carefully  for  the  best  products  to  achieve  its  goals  for  interoperable  and  affordable 
systems.  As  we  have  already  discovered  in  the  area  of  information  technology,  DoD  needs  to  follow  and  influence 
where  it  can  through  standards  groups.  Ideally,  well  defined,  widely  used,  non-proprietary  standards  are  preferred; 
however,  widely  used  standards  usually  dominate  as  the  best  choice  to  build  OS.  Widely  used  standards  may  be 
open  (public),  owned,  de  facto,  or  proprietary.  Systems  that  adhere  to  the  standards  achieve  a  level  of  Openness  that 
correlates  to  increased  interoperability  and  affordability.  The  level  of  Openness  determines  the  extent  to  which  a 
weapon  system  can  use  multiple  suppliers,  insert  new  hardware  and  software,  and  assign  control  of  design,  repair  and 
replacement. 
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Sometimes  “Less  Open”  is  the  Best  Answer 

-  But  the  Burden  of  Proof  Should  be  Rigorous  - 


•  OS  Process  presumes  “most  Open,”  but  that  is  not  always  feasible;  less  Open 
is  sometimes  desirable  in  upgrades  of  legacy  systems  with  limited  remaining 
lifetimes  where  adoption  of  Open  standards  is  not  economically  feasible 

•  Less  Open  often  applies  when: 

-  Easiest  subsystem  or  component  changes,  upgrades,  or  replacement  are  not 
needed 

-  Cost  effective  insertion  of  rapidly  advancing  technology  is  not  required  during 
remaining  life  cycle 

-  Cost  reduction  through  competition  is  neither  viable  nor  economically  desirable 

•  Sometimes  less  Open  solutions  really  do  enable  better  CONOPS, 
supportability,  functionality,  and  even  total  life  cycle  costs 


A  pure  “Open”  world  would  be  best  for  DoD.  DoD  should  presume  that  any  and  all  recommended  solutions  will  be  truly 
Open,  and  there  should  be  a  rigorous  burden  of  proof  for  those  who  would  configure  otherwise. 

Having  said  that,  we  live  in  a  more  complex  world  full  of  examples  of  less-Open  solutions  which  are  truly  the  best 
answer  for  the  particular  situation.  The  issue,  from  the  OSTF  perspective,  is  less  about  insisting  that  all  solutions  be 
Open  in  the  pure  sense,  than  assuring  that  configuration  decisions  are  well  considered.  And  here  is  the  mb. 

The  power  of  ready  integration  accrues  only  when  the  requisite  attributes  are  wide  spread.  There  are  numerous 
motivations  at  a  local  level  to  pursue  less  Open  solutions.  It  will  take  strenuous  discipline  and  a  more  global  perspective 
to  achieve  true  modularity  across  DoD. 

Legacy  systems  present  a  unique  problem  because  legacy  system  upgrades  for  the  sake  of  Openness  alone  are  not  usually 
feasible.  Usually,  significant  system  development  in  a  legacy  system  presents  an  opportunity  to  incorporate  standards 
and  design  changes  to  improve  system  Openness.  However,  many  of  the  DoD’s  legacy  systems  have  stabilized  to  the 
point  that  the  insertion  of  rapidly  advancing  technology  is  not  required  during  the  remaining  life  cycle.  Integration  of  OS 
standards  and  designs  may  not  be  economically  feasible  with  such  systems.  Exceptions  can  also  apply  when  developing 
a  new  system.  New  system  development  may  be  less  Open  because  cost-reduction  through  competition  is  neither  viable 
nor  economically  desirable. 

OS  can  have  some  drawbacks  if  not  applied  judiciously.  Blindly  forcing  Open  standards  and  designs  may  seriously 
impact  performance,  operational  capability,  or  create  excessive  costs.  There  are  no  silver  bullets  that  can  be  applied 
uniformly  across  all  systems.  Only  through  sound  system  engineering  principles  can  DoD  obtain  affordable  and 
sustainable  80%  solutions  rather  than  ideal  solutions  which  are  neither  affordable  nor  sustainable. 
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Choosing  Standards 


Openness 


•  Criteria  (some  may  be  in  conflict  -  requires  engineering  and  business  judgment): 

-  Consistency  with  the  architecture 

-  Does  it  work  well  in  this  application? 

-  Degree  of  Openness,  breadth  of  use,  and  continued  support 

-  Robust  capability  for  future  evolution  of  system  throughout  life  cycle 

-  Extent  of  Plug  &  Fight  (ex:  coalition  warfare  — ►  commercial  standards) 

•  Increased  care  must  be  used  when: 

-  A  standard  has  not  matured  (e.g.,  CORB  A) 

-  Proprietary  extensions  necessary  for  performance  requirements 

-  Multiple  standards  exist  for  the  same  function 

-  A  standard  docs  not  exist  and  new  work  needs  to  be  reusable 

-  Avoid  hollow  standards! 

“Practical  Open  **-  Widely  used  and  supported,  as  Open  as  practical  g 
(wide  use  outweighs  Openness)  | 
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Interface  standards  are  of  course  selected  in  the  context  of  the  system  architecture  which  they  will  serve.  External 
conditions  are  also  important.  For  example,  in  the  graphic  above,  Openness  is  plotted  against  Widespread  Use.  “Iso¬ 
goodness”  curves  suggest  that  widespread  market  acceptance  and  support  have  more  utility  for  DoD  than  pure 
Openness.  Thus,  MS  Office  is  widely  used  although  it  is  a  proprietary  product. 

Industry  can  contribute  to  the  standards  selection  process  if  clear  success  criteria  are  articulated  by  the  government. 
Examples  of  external  conditions  to  be  considered  are: 

A  standard  has  not  matured.  A  specification  exists,  but  either  products  have  not  been  created  or,  if  the  product  has 
been  created,  it  has  not  been  tested  in  an  adequate  number  of  contexts.  An  example  of  this  situation  is  the  Common 
Object  Request  Broker  Architecture  (CORBA).  The  specification  preceded  an  implementation.  As  products  became 
available  and  the  specification  was  tested,  it  quickly  became  obvious  that  CORBA  was  well  suited  for  some 
applications,  but  not  appropriate  for  all  applications.  Within  DoD  there  was  considerable  pressure  to  select  CORBA 
as  the  middleware  for  software  systems.  Since  CORBA  is  not  appropriate  for  all  applications,  settling  on  CORBA  as 
the  standard  for  all  applications  would  have  been  premature. 

Proprietary  extensions  are  needed.  The  specifications  may  be  complete,  but  do  not  support  system  performance 
requirements.  SQL  is  an  example  of  this  condition.  There  are  few  developers  that  adhere  to  a  strict  implementation  of 
SQL  because  they  cannot  get  the  database  performance  necessary  to  meet  the  system  performance  requirements. 
Developers  frequently  depend  on  proprietary  extensions  that  cause  a  tighter  coupling  to  the  database  vendor  (i.e.  more 
sole  source)  than  a  more  OS  approach  would  dictate. 
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Multiple  standards  exist.  Multiple  standards  can  meet  requirements,  but  an  engineering  analysis  must  be  done  to 
select  the  most  appropriate  product.  However,  the  decision  can  result  in  losses  such  as  flexibility  and  scalability,  or 
can  result  in  increased  costs  down  the  road.  CORBA  and  DCE  support  distributed  computing  are  both  acceptable 
choices  within  the  JTA;  however,  both  support  different  software  architectures.  Selecting  the  standard  before  the 
software  architecture  is  developed  forces  the  architecture  to  be  consistent  with  the  product,  instead  of  selecting  the 
architecture  because  it  is  the  best  fit  for  die  problem.  This  is  also  an  example  demonstrating  that  standards  are  not  a 
substitute  for  software  engineering. 

A  standard  does  not  exist.  System  design  may  call  for  a  specific  architecture  or  software  component  that  does 
not  have  an  existing  standard.  This  can  occur  because  the  product  is  militarily  unique,  or  no  standard  exists  in  the 
marketplace.  For  example,  messaging  and  queuing  products  do  not  adhere  to  a  standard. 

No  decision  is  black  and  white.  Decision  makers  must  consider  the  desired  attributes  for  the  system.  Decisions 
must  be  made  considering  the  context  of  the  desired  system  properties. 
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Risks 


•  Risks  associated  with  “more  Open”  options  include: 


-  Budget  and  Service  investment  philosophy: 

•  Upfront  $$  required  for  OS  Process  systems  engineering 

-  Backward  compatibility  within  legacy  systems  can  be  expensive 

-  Need  to  sway  industry  standards  bodies;  requires  early  proactive  involvement 

-  Industry  concerns  over  proprietary  data  and  investment  for  competitiveness 

-  Availability  of  standards,  their  evolution  &  obsolescence 

-  Market  acceptance  of  emerging  standards  not  assured;  need  backup  plans 

•  But,  taking  a  chance  and  guessing  wrong  is  still  “cheaper,  faster,  better”  than 
developing  a  DoD-unique  solution 

•  Enabling  future  reuse  requires  additional  $$,  offset  by  reducing  recurring  test  $$  — 
ex:  recurring  SW  regression  testing  costs  DoD  SB/year 

-  Numerous  methodologies  and  technical  challenges,  but  within  our  grasp 


Even  with  all  this,  U.S.  government  process  impediments  are  the  single  greatest 
risk 


Risks  are  real,  but  are  dwarfed  by  the  benefits; 
Up-front  funding  a  major  problem 
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Achieving  the  benefits  of  OS  requires  changing  a  huge,  entrenched  bureaucracy,  richly  endowed  with  inertia,  risk 
aversion,  and  accepted  wisdom.  Thus,  process  impediments  provide  the  most  imposing  obstacle  to  realizing  the 
benefits  of  OS. 

Accordingly,  the  OSTF  recommends  that  the  OS  Process  for  system  analysis  be  mandatory.  At  the  same  time,  the 
OSTF  recognizes  that  making  something  mandatory  introduces  other,  different  risks  -  i.e.: 

•  The  risk  of  creating  more  bureaucracy,  and,  with  it,  more  inertia,  more  risk  aversion,  and  a  new  category  of 
accepted  wisdom.  This  risk  is  minimized  by  incorporating  OS  constraints  into  the  current  processes,  executed 
by  people  in  existing  structures,  rather  than  by  creating  new  organizations. 

•  The  risk  that  the  mandatory  additions  and  amendments  to  current  processes  will  be  worked  around  or 
otherwise  ignored.  This  risk  is  minimized  by  conspicuously  attaching  the  OS  movement  to  the  SecDef  s  aim 
to  create  a  revolution  in  defense,  paid  for  by  a  revolution  in  business  practice. 

•  Nevertheless,  the  OSTF  believes  that  bets  have  to  be  made  because  occasionally  guessing  wrong  is  far  better 
than  never  guessing.  An  immediate  corollary  is  that  mechanisms  have  to  be  found  to  protect  the  careers  of 
those  who  make  the  guesses. 

•  Another  major  obstacle  is  fear  of  failure,  which  often  translates  into  a  fear  that  bets  made  on  standards  will  be 
losing  bets  for  reasons  beyond  the  control  of  the  DoD  and  beyond  the  predictive  capabilities  of  even  the  wisest 
technologists.  Shrewd  suppliers  may  use  standards  as  much  to  fight  competitors  as  to  improve  the  lot  of 
buyers’  buyers.  Accordingly,  the  standards  that  emerge  and  survive  in  the  marketplace  may  not  necessarily 
be  the  best  choices  technically. 
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Major  changes  are  always  fodder  for  those  who  focus  on  pointing  out  problems  rather  than  solving  problems,  and 
movement  toward  Openness  will  provide  an  abundance  of  such  fodder.  Nevertheless,  the  OSTF  believes  that 
with  support  at  the  SecDef  level,  all  the  challenges  can  be  overcome,  and  benefits  realized. 

One  such  challenge  emerges  because  the  DoD  no  longer  has  the  market  share  to  call  the  shots.  Accordingly,  it  is 
essential  that  DoD  provide  early,  proactive  leadership  in  standards  bodies.  Equally,  in  the  event  the  standards  do 
not  evolve  in  the  right  direction,  or  do  not  exist,  then  there  must  be  a  backup  plan. 

Of  course,  technical  people  enjoy  technical  elegance,  so  it  is  important  to  avoid  natural  tendencies  to  embellish 
requirements,  thus  locking  out  the  industry  standard.  Here,  enlightened  leadership  is  needed;  it  must  be 
understood  that  adapting  a  standard  is  generally  equivalent  to  rejecting  a  standard. 

Next,  leadership  has  to  realize  that  not  all  variables  can  be  optimized  simultaneously,  so  managers  must  be  trained 
to  look  not  only  at  the  goals  at  their  own  level,  but  at  the  goals  of  levels  above.  For  example,  although  the 
multiple-vendor,  nonproprietary  choice  is  preferred,  it  may  be  the  choice  that  leads  to  enormous  cost,  thus 
contravening  a  key  high-level  goal  motivating  OS  in  the  first  place. 

A  more  subtle  problem  is  that  the  wide  use  and  “lack  of  genetic  diversity”  make  OS  inherently  more  vulnerable  to 
information  warfare  attacks.  While  worrisome,  the  vulnerability  introduced  by  OS  is  not  necessarily  substantial, 
and  should  not  inhibit  the  use  of  OS. 

Another  subtle  problem  has  to  do  with  proprietary  interests.  The  interests  of  suppliers  are  not  necessarily  well 
aligned  with  the  interests  of  the  DoD  in  the  Openness  dimension.  Historically,  suppliers  have  made  more  money 
with  non-Open  systems.  Additionally,  there  are  legitimate  intellectual  property  concerns.  Such  problems  are 
difficult,  but  not  insuperable,  given  the  will  to  combine  firm  OS  requirements  with  procurement  innovation,  all 
backed  by  SecDef  level  support. 

Finally,  time  and  resources  have  to  be  spent  to  save  money.  Rearchitecting,  problem  solving,  and  organizational 
change  consume  resources.  Industry  examples  demonstrate  that  strong  will  needs  to  accompany  strong  desire  if 
major  change  is  to  take  place. 
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Managing  to  Natural  Cycle  Rates 

-  Parsing  Systems  by  Natural  Cycle  Rates  - 

•  Mildly  constrained 

ex.  Command  Post,  including  airborne  &  mobile;  shipboard  and  sub  electronics 

-  Rack  typically  isolates  boards  from  platform  environment 

-  Adequate  weight,  space,  power,  cooling;  rack  interconnects  flexible 

-  High  leverage  of  commercial  technical  and  business  practice 

•  Severely  constrained 

ex.  tactical  missiles 

-  Some  commercial  components  but  not  boards 

•  Tightly  constrained 

ex.  Tactical  aircraft  avionics 

-  Enclosure  can  isolate  boards  from  platform  environment 

-  Tightly  constrained  weight,  space,  power,  cooling 

-  Enclosure  interconnects  inflexible 

-  Can  achieve  many  commercial  advantages,  but  need  new  approaches 
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Our  acquisition  processes  and  system  designs  need  to  enable  and  synchronize  with  the  natural  cycle  rates  of  the 
system  components.  We  have  not  typically  designed  low  cycle-rate  platforms  (airframe,  hull,  vehicle)  to  marry 
up  with  evolving  high  cycle-rate  components  (electronics)  downstream.  The  high  cycle-rate  products  which  we 
can  specify  in  detail  at  concept  definition  time  are  not  what  we  will  take  to  production  nor  support  in  the  field,  nor 
are  the  attributes  we  test  in  EMD  what  we  take  to  production  (ex.,  we  should  quality  test  software  early  and 
processor  host  hardware  late).  Therefore,  frequent  technology  renewal,  even  during  design  and  production,  is  a 
“must  do”  to  maintain  sources  and  support. 

The  high  cycle-rate  items  are  mostly  electronics,  and  most  DoD  electronics  can  be  readily  configured  for  good 
commercial  OS  Processes.  Isolating  the  commercial  elements  from  the  platform  environment  is  preferable  to 
MILSPEC  hardening  (ex.,  we  already  have  commercial  boards  on  tactical  vehicles,  surveillance  aircraft, 
submarines).  Therefore,  one  way  to  manage  to  natural  cycle  rates  is  to  parse  our  systems  by  platform 
environment.  This  slide  portrays  a  notional  concept  of  platform  environments  and  describes  how  each 
environment  influences,  or  constrains,  our  use  of  commercial  products  to  meet  mission  requirements. 


10/19/98  14:25 


DSB  OSTF  FINAL  REPORT 


DSB  OSTF  FINAL  REPORT 


The  March  of  Technology  Ought  to  be  Saving  Programs 

-  Managing  to  Let  It  Happen  - 


March  of  Technology—  Radar  Processor  example 
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Think  of  systems  and  processes  as  the  means  to  harness  change: 
Encourage  natural  cycle  rates,  synchronizing  at  key  milestones 
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Synchronization  Milestones 


•  Cycling  continues  throughout  the  entire  life  of  the  program;  PM  responsible  for  full  life 

•  Measures  needed  for  sustainment  also  needed  for  HMD 

•  Controls  configuration  with  architecture  and  F3  “sockets”,  not  at  piece/part  level 

•  OS  architecture  enables  concepts  such  as  Spiral  Development  and  Evolutionary  Acquisition 
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Technology  is  advancing  at  an  extraordinary  rate,  particularly  in  electronics  and  information  technology.  The  top 
graphic  estimates  the  advance  of  Airborne  Radar  Signal  Processing  over  about  25  years,  compared  to  the 
deployment  cycle  of  air  superiority  aircraft  (ex.  F-22).  We  would  expect  such  multiple  quantum  technology 
improvements  to  be  miraculous  windfalls  for  the  development  program,  perhaps  even  saving  the  program  in  a 
down  budget. 

But  such  is  usually  not  the  case.  Why?  Because  our  program  management  and  oversight  processes  are  amazingly 
poor  at  capturing  advantageous  advances.  In  fact,  the  processes  are  so  rigid  that  improvements  actually  destabilize 
programs  and  become  a  threat.  In  the  current  era,  change  is  so  frequent  and  profound  that  we  cannot  keep  our 
systems  viable  and,  as  a  consequence,  programs  are  at  best  troubled  at  every  stage  of  their  life  cycle;  at  worst, 
some  are  dying.  IEWCS  saved  a  whole  suite  of  programs  that  would  otherwise  have  lapsed  as  unaffordable;  F-22 
can  not  keep  its  configuration  stable  long  enough  to  get  through  EMD.  Ironically,  many  of  the  measures 
necessary  for  full  life  cycle  viability  and  often  unfunded  by  the  Services  are  now  necessary  just  to  get  through 
EMD. 

Re-envisioning  our  systems  and  our  program  management  processes  is  a  survival  issue 

We  are  absolutely  assured  of  the  rapid  evolution  of  requirements,  external  interfaces,  and  the  component  building 
blocks  of  our  systems.  Instead  of  designing  programs  to  withstand  the  ravages  of  change,  we  must  configure  our 
systems  and  management  processes  to  be  crucibles  to  leverage  change  for  continued  relevance  and  viability.  We 
must  revamp  management  processes  to  permit  the  underlying  components  to  cycle  at  their  natural  cycle  rates, 
while  having  the  whole  synchronize  at  key  configuration  milestones,  such  as  fabrication  of  qualification  articles  or 
release  of  Long  Lead  for  Low  Rate  Initial  production  (LRIP). 
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Upon  examination,  we  note  system  components  can  be  parsed  into  groups  with  significantly  different  cycle  rates. 
Basic  platform  structures,  for  example,  are  often  stable  for  20-30  years,  and  we  now  have  40-50  year  examples 
(B-52s).  By  contrast,  basic  architectural  elements  such  as  operating  systems  and  backplanes,  electronic 
enclosures,  and  engine  interfaces  may  be  stable  for  10-15  years  or  so.  Electronic  components  may  lapse  after 
18-36  months.  A  program  manager  today  knows  that  he  will  probably  have  to  evolve  his  operating  system  and 
backplane  structure  before  the  first  production  run,  and  that  qualification  test.  Initial  Operational  Test  and 
Evaluation  (IOT&E),  and  LRIP  product  will  all  have  different  board-level  electronic  components.  So  he  also 
knows  that  it  will  be  nearly  impossible  to  maintain  all  the  same-type  aircraft  on  base  at  an  identical  configuration, 
and  it  is  unlikely  that  even  any  two  aircraft  are  identical  at  any  point  in  time. 

Clearly,  DoD  must  tailor  the  system  configuration  and  program  management  processes  to  the  natural  cycle  rates 
of  the  products.  We  must  view  systems  as  a  construct  of  F3I  “sockets”  which  permit  asynchronous  evolution  of 
the  components  which  plug  into  each  socket.  We  must  assure  the  operational  adequacy  of  the  functionality  of 
the  overall  architecture.  To  capture  the  enormous  advantages  of  a  very  dynamic  industrial  base,  we  must  adopt  a 
hierarchy  of  subordinate  architectures  to  permit  lower  tier  participants  to  evolve  at  the  subsystem,  board,  and 
piece  part  levels. 

Such  robust  architectures  will  enable  a  whole  range  of  DoD  objectives  such  as  reduced  cycle  time  and  reduced 
life-cycle  costs,  and  management  strategies  such  as  Spiral  Development  and  Evolutionary  Acquisition. 
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Product  Configurations  to  Enable  High  Cycle  Rates 

-  Decoupling  System  Elements  - 


SOFTWARE 


T AC AIR  avionics  —  a  stress  case  and  major  investment  cost 


HARDWARE 


Architecture,  language,  and 
operating  system  provide 
medium  cycle-rate  stability 


AIRCRAFT  PORTION 
(racks,  cables,  connectors) 

•  Inflexibility,  poor  reliability 

•  Massive  upgrade  cost 

•  Stifles  currency 

PLUG  *  PLAY  AVIONICS  ENCLOSURES 

*  High-performance  board  F3I,  backplane 

’  Robust  connections  to  cockpit  and 
outboard  equipment  bays 

’  Avoids  many  aircraft-side  failures  and 
upgrade  $$$ 

*  Subsystem  evolution  addressed  at  board  level 


System  Elements  Decoupled 
Software 

Arch,  language,  op  sys, 
Applications,  (processor) 


Cycle  Rate 
Low  (20-30  yrs) 
Medium  (10-15  yrs) 
High  (3-5  yrs) 


Hardware 
Air  Frame 
Enclosures,  cabling 
Board  components 


Product  domains  can  be  decoupled;  natural  cycle  rates  can  be  enabled 


Is  it  plausible  to  configure  actual  products  to  permit  asynchronous  cycling  of  underlying  components?  The  OSTF 
examined  TACAIR  avionics  as  a  highly  leveraged  stress  case  —  aviation  overall  is  a  major  (<50%)  portion  of  the  DoD 
investment  accounts,  a  significant  portion  of  complex  aircraft  costs  is  avionics,  and  many  avionics  assemblies  are 
difficult. 

There  are  both  hardware  and  software  constructs  which  decouple  components,  potentially  enabling  asynchronous 
cycling  of  high  rate  items  and  even  medium  rate  architectural  elements. 

A  layered  software  approach  -  such  as  represented  by  the  graphic  to  the  left  —  has  been  used  by  recent  programs  such 
as  the  LM  Submarine  BSY-2  Combat  System  replacement  and  the  Boeing  Oscar  TACAIR  data  processor.  Cycling  on 
the  bottom-most,  high  cycle-rate  hardware  host  layer  is  isolated  by  the  Board  Support  Package  Layer,  while  the 
resource  controller  isolates  application  programs  —  potentially  also  high  cycle  rate  components  —  from  each  other  and 
the  rest  of  the  stack.  The  isolation  cuts  both  ways:  not  only  can  the  high-cycle  rate  components  cycle  frequently,  but 
the  medium-cycle  rate  operating  system  and  its  language  can  also  evolve  without  overly  impacting  the  hardware  and 
application  layers.  With  this  high  modularity,  the  overall  processing  architecture  can  also  evolve  as  subsystems 
repartition  over  time  —  as  is  occurring  with  radar  signal  processing.  Diverse  functions  can  share  processing  resources, 
accruing  benefits  of  integrated  processing  while  maintaining  much  of  the  attractive  isolation  of  federated  schemes. 

Similarly,  the  graphic  to  the  right  suggests  a  modular  hardware  configuration  facilitating  high  isolation,  avionics 
evolution,  and  commercial  economies.  This  scheme  consolidates  avionics  in  a  few  central  enclosures  as  is  done  on  the 
F-22,  but  with  standard  commercial  backplane  and  board  interfaces.  Enclosures  aye  connected  by  standard 
transmission  interfaces.  Processors  can  be  shared  or  dedicated.  With  standard  commercial  board  interfaces, 
subsystems  can  repartition  and  on-board  technology  can  evolve  without  impacting  other  functions.  Board  counts  can 
change  and  slots  can  be  reassigned.  New  interconnects,  such  as  fiber,  can  be  overlaid  as  needed.  The  infrequent 
evolution  of  the  backplane  and  board  interfaces  can  be  approached  more  as  a  repackaging  problem  than  a  major  block 
change. 

Such  an  architecture  allows  underlying  system  components  to  be  decoupled  and  able  to  cycle  at  their  natural  rate. 
Only  by  adopting  such  architectures  will  major  systems  be  able  to  stay  viable  throughout  their  acquisition  and 
operational  lifetimes. 
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Configuring  Systems  for  High-Cycle-Rates  Components 

•  High  cycle-rate  items  are  mostly  electronics 

•  Most  DoD  electronics  can  be  readily  configured  for  good  commercial  OS  Processes 

-  Isolating  commercial  elements  from  platform  environment  preferable  to  MILSPEC  hardening  (ex:  already 
have  commercial  boards  on  tactical  vehicles,  surveillance  aircraft,  subs) 

-  Permits  frequent  technology  refresh  to  preserve  suppliers,  relieve  problems,  reduce  costs 

-  Need  good  F3I  at  enclosure  and  board  level 

-  Well  partitioned  functions  enable  asynchronous  evolution,  modernization  through  spares 

-  Subsystems  can  even  be  rearchitected  (ex.  repartitioning  signal  and  data  processing) 

-  Suppliers  can  refresh  boards  as  needed;  minimum  platform  and  subsystem  impact 

-  Commercial  standards  --  offer  most  benefits,  but  works  even  when  unique  (ex.  tac  missiles) 

•  Apply  philosophy  on  a  broad  scale  in  other  domainsfex  electro-mechanical,  power  supplies) 


Axiom 

Manage  enclosures  as  PI  sockets,  not  as  frozen  configuration  items; 
Let  board  configurations  cycle  as  needed  within  the  F5  standard 
to  accommodate  rearchitecting  and  high  cycle-rate  components 
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Although  many  areas  of  technology  are  cycling  much  faster  now  than  in  the  past,  the  effect  is  seen  most  profoundly 
in  electronics  systems.  In  the  past,  DoD  insisted  on  MIL-SPEC  components  that  had  to  operate  over  a  wide  range 
of  environmental  conditions.  Most  commercial  components  will  not  meet  the  MIL-SPEC  conditions.  Two 
approaches  can  be  taken  to  solving  this  problem.  The  first  is  to  make  sure  that  our  specifications  reflect  that  actual 
conditions  that  will  be  seen.  The  second  is  to  isolate  the  commercial  component  from  the  military  environment 
through  proper  design  of  enclosures,  boards,  and  packaging. 

A  well  designed  modular  architecture  will  permit  a  strong  F3I  attribute  at  the  board  and  enclosure  level,  permitting 
the  use  of  commercial  items  inside  that  isolated  and  controlled  environment. 

Well  designed  modularity  also  permits  the  components  inside  each  module  to  cycle  at  their  natural  rate,  and  to  be 
refreshed  with  new  technology  as  needed.  It  will  even  be  possible  to  rearchitect  subsystems  as  needed  without 
unduly  affecting  the  overall  system,  provided  that  the  F3I  socket  interfaces  remain  under  control. 
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Open  Systems  Process  Status 

-  Force  Level  - 

Forces  have  embraced  OS  attributes  only  in  very  narrow  areas 

(ex:  some  C4ISR  interoperability) 

Not  embraced  as  a  broad  enabler,  even  in  areas  of  seemingly  equal  importance 

(ex;  interoperability  of  logistics  management  processes ) 

•  OS  Process  for  JV20 1 0 

-  Impelling  grass  root  initiatives  (ex.  Pacific  Fleet  Command  ships) 

-  Do  not  see  substantive  funding  of  real  projects  within  U.S.,  nor  within  allies  and  coalition  partners 

•  Joint  planning,  deployment,  battle  management,  engagement,  sustainment 

•  Time  to  first  significant  FTX  longer  than  WW II 

-  Joint  capabilities  accepted  at  personal  level,  but  don’t  compete  in  Service  budgets 

•  OS  Process  in  general 

-  Not  cornerstone  of  vision  for  long-range  viability  and  effectiveness 

•  Minimal  requirements,  plans,  investment,  metrics,  training,  etc. 

-  Minimal  Service  commitment;  not  seen  as  high-leverage  solution 

•  Perceived  very  narrowly  —  fix  specific  problems;  minimum  initial  cost,  performance 

•  Weak  follow-through  on  current  policies  and  directives;  few  penalties  for  non- 
compliance 

•  Services  activities  are  generally  unique  (Title  1 0  prerogatives) 


One  would  expect  our  forces  to  be  able  to  interoperate  in  all  important  domains,  as  envisioned  by  JV2010. 
Unfortunately,  there  is  precious  little  increase  in  emphasis  or  funding  for  OS  attributes  as  a  result  of  Joint  Vision 
2010  and  the  Service  equivalents. 

Backfitting  interoperability  into  legacy  systems  is  an  exasperating  and  sometimes  expensive  enterprise,  and  legacy 
upgrades  compete  poorly  against  new  systems  in  Service  budgets.  Nevertheless,  the  Army  has  shown  that  it  can  be 
done  even  within  a  Service  budget,  and  the  Army  has  been  enhanced  by  these  efforts.  That  experience  has  not  been 
generalized  across  DoD. 

There  has  been  some  modest  progress  in  the  narrow  areas  of  joint  C^ISR,  electronics,  and  computers.  Extension  of 
the  JTA  concept  to  other  domains  such  as  logistics  visibility  and  management  systems  is  painfully  slow.  The 
Services  are  doing  somewhat  better  internally  but  these  efforts  are  often  unique  (Title  10  prerogatives)  and  do  not 
necessarily  lead  to  increased  ability  to  integrate  composite  force  elements  as  needed. 

It  is  instructive  that  achieving  a  truly  interoperable  JTA  has  been  such  a  struggle.  DoD  clearly  has  not  yet  arrived 
at  a  common  objective  or  agreement  on  a  general  approach.  For  example,  the  Air  Force  sees  the  JTA  as  strictly 
limited  to  information  interoperability,  while  the  Army  argues  to  include  affordability  and  commonality  measures. 
Clearly  topics  like  affordability  and  commonality  need  to  be  significantly  addressed  one  way  or  another  or  the 
investment  foundation  of  the  evolving  warfighting  visions  will  not  materialize. 

The  OSTF  does  not  expect  to  see  significant  progress  at  the  force  level  until  the  ability  to  genuinely  integrate  force 
elements  becomes  a  major  DoD  priority. 
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Open  Systems  Process  Status 

-  Force  Level  (cont.)  - 

•  Little  management  attention  to  exploiting  OS  to  meet  challenges 

-  Few  plans  (OS  Process  not  internalized  or  incorporated  into  daily  processes) 

-  Few  metrics  (no  means  to  evaluate  cost  savings) 

-  Little  training 

-  Little  investment 

-  Inadequate  follow  through  on  current  policies  and  directives 

-  Few  penalties  for  non-compliance 

•  The  Services  are  not  currently  committed  to  OS 

‘Acceptance  of  OS  is  through  Commitment 
—  Active  leadership 

-  Emphasis  on  people  and  training 

-  Participation  in  standards  organizations 

IIV19**  14:25 
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By  any  of  the  measures  one  would  use  to  judge  the  degree  of  institutionalization  of  a  concept  or  process,  OS  is  still  in  the 
introductory  stage.  Plans  are  currently  scarce  and  weak.  Even  in  the  case  of  requirement  plans  such  as  Transition 
Planning,  compliance  and  quality  has  been  checkered.  Few  metrics  are  in  place  and  far  less  training.  The  OSD  OS-JTF 
has  done  well  to  supply  materials  such  as  a  CD-ROM  Desk  Reference  to  the  acquisition  community  but,  for  example,  the 
subject  is  not  taught  at  the  Defense  Systems  Management  College  (which,  admittedly,  has  a  glut  of  topics  to  teach  in  a 
short  academic  period). 

While  there  are  exciting  projects  in  the  Services  achieving  astounding  results,  these  examples  cannot  be  generalized  to 
the  overall  state  of  affairs.  Taken  as  a  whole,  it  would  be  difficult  to  argue  that  the  Services  are  committed  to  an 
aggressive  OS  approach. 
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Open  Systems  Process  Status 

-  Acquisition  and  Support  - 

•  Potential  is  staggering;  exciting  initiatives  underway 

-  OS-JTF  &  DARPA  pilot  programs,  Joint  AeroCommanders’  Group  F3! 

-  Cross-system  work  (F-15//F/A-18//AV-8B;  Sub  Combat  System) 

•  But  generally,  DoD  doing  poorly 

-  Not  yet  truly  embraced  by  Services  or  most  Program  Offices 

-  Don’t  yet  have  a  unifying  concept;  hampers  institutionalizing  process 

-  Hobbled  by 

•  Inadequate  appreciation  of  the  benefits  of  an  OS  Process 

•  Poor  plans,  processes,  training,  funding  flexibility,  metrics,  compliance  with  policies  &  directives 
■  Rigid  statutes,  policies,  bureaucracy 

•  Inadequate  top-down  emphasis  and  structured  incentives 

-  The  fundamental  problems  are  common  across  new  and  legacy  systems  alike 

-  Legacy  systems  and  sustainment  are  particularly  disadvantaged 

•  Crippled  by  old  architectures 

•  Legacy  upgrades  compete  poorly  in  current  budget  crunch 

•  Absence  $$$,  little  progress  likely 

OS  could  have  massive  benefits,  but  OS  Process  has  not  really  arrived;  I 
Our  management  processes  are  crippling,  self-inflicted  barriers  | 


It  is  irrefutable  that  an  OS  Process  can  turn  around  systems  and  save  missions.  There  are  massive  benefits  to  be 
gained.  While  specific  pilot  programs  are  turning  in  exciting  results,  it  is  fair  to  say  that  DoD  is  poor  to  abysmal  in 
truly  embracing  OS  attributes  in  acquisition  and  support  programs. 

Although  submittal  of  OS  Implementation  Plans  has  been  directed  upon  the  Services,  the  resulting  plans  generally 
have  been  found  to  be  of  poor  quality,  and  compliance  with  the  plans  has  been  checkered  at  best.  However,  there 
are  DoD  organizations,  programs,  and  contractors  pursuing  various  benefits  of  OS  and  related  elements  such  as 
COTS  products,  commercial  items,  and  commonality.  Although  we  found  increasing  local  enthusiasm  for  OS  and 
commercial  products,  we  didn’t  find  a  well  structured  program. 

The  Dec  1997  OS-JTF  survey  of  552  program  office  personnel  representing  232  weapons  systems  programs  across 
DoD  found  that  most  respondents  were  aware  of  OS  and  its  advantages,  but  that  the  majority  of  program  offices  do 
not  have  a  written  process  or  procedure  for  implementing  OS  policy.  The  level  of  awareness  was  thought  to  be  less 
in  related  activities  such  as  requirements  and  logistics.  Technical  impediments  were  reported  by  70%  of  the 
respondents;  65%  reported  significant  institutional  and  cultural  barriers.  Most  of  the  problems  reported  were 
common  among  new  and  legacy  systems  and  were  compounded  by  such  factors  as  lack  of  training,  absence  of  real 
incentives,  and  budget  deficiencies  and  inflexibility. 

The  OSTF  explored  the  issue  of  supportability  in  terms  of  the  relationship  between  OS  and  the  vision  of  focused 
logistics  as  expressed  in  Joint  Vision  2010  and  supporting  service  documents.  We  found  a  number  of  government 
agencies  and  contractors  who  touched  on  various  benefits  of  OS  architecture  and  elements  related  to  OS 
architecture  such  as  COTS  products  and  commonality.  Although  we  found  enthusiasm  for  OS  and  commercial 
products,  we  didn’t  find  a  well-structured  set  of  guiding  principles  supporting  facts  about  the  impact  of  OS  on 
achieving  the  goals  of  focused  logistics. 
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The  core  problem,  we  believe,  is  that  OS  are  not  truly  embraced  by  the  leadership.  While  there  are  encouraging 
exceptions,  there  is  generally  a  lack  of  leadership  commitment,  understanding,  and  incentives;  and  the  disincentives 
are  monumental.  Leadership  is  crucial  in  that  successful  implementation  requires  a  series  of  champions  throughout 
the  line  of  command.  A  unifying  concept  OS  Process  is  probably  essential  for  addressing  these  problems. 

It  is  clear  that  most  of  the  identified  problems  are  common  across  new  and  legacy  systems;  and,  from  a  process 
perspective,  so  are  the  solutions.  But  legacy  systems  are  particularly  hampered  by  budget  deficiencies.  As  the  overall 
defense  budget  has  become  more  stressed,  and  as  investment  accounts  are  increasingly  the  bill  payers  for  other 
priorities,  the  Services  have  chosen  to  focus  the  meager  remaining  funding  on  protecting  their  highest  priority  new 
programs  in  the  current  budget  year.  A  result  is  a  dearth  of  funding  for  upgrading  legacy  systems. 

Numerous  studies  have  concluded  that  significant  efficiencies  in  the  sustainment  accounts,  such  as  offered  by  the  OS 
Process,  would  free  up  significant  funding  for  new  systems  —  even  after  paying  the  up-front  development  necessary 
for  the  upgrades  —  allowing  more  funds  to  go  for  modernization.  Funding  for  such  upgrades  has  not  been  forthcoming 
as  the  Services  continue  to  focus  on  current  year  problems.  Some  modest  improvements  are  being  pursued  with  such 
laudatory  initiatives  as  the  Army’s  “Modernization  Through  Spares.”  But  without  funding  for  rearchitecting  and 
upgrading,  significant  improvement  will  not  be  possible. 
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Revamping  Processes  and  Tools 

The  reengineering  of  DoD  processes  and  tools  is  itself  a  systems  engineering  task  — 
Need  an  integrated  approach  to  the  whole  program  management  and  oversight  process 

•  Mindset  and  Core  Values,  Behavior 

•  Requirements 

•  Program  Management 

•  Specifications  and  Contracting 

•  Test  and  Evaluation 

•  Funding 


Need  to  cover  all  elements  of  the  system  life  cycle 


For  decades  the  development,  test,  support,  and  oversight  of  DoD  system  has  been  organized  around  a  concept  of 
baselining  to  a  “final  configuration”  and  stoutly  resisting  change,  a  kind  of  ffeeze-and-build  siege  mentality.  This 
“final  configuration”  mindset  is  institutionalized  in  program  management  education  and  practice,  the  structure  of 
critical  tools  such  as  cost  analysis  models,  the  formal  system  development  process,  our  philosophy  of  test,  support 
concepts,  and  milestone  review  and  oversight  criteria.  The  “final  configuration”  perspective  is  a  pervasive 
consistency  and  an  entrenched  core  value. 

This  historic  DoD  “final  configuration”  perspective  needs  to  be  replaced  with  the  new  OS  Process  concepts  of 
pervasive,  architecture-driven  modularity,  life  long  system  viability,  and  management  processes  which  nurture 
change. 

This  is  a  major  redirection  of  the  very  mindset  and  culture  of  the  govemment/Industry  acquisition  community.  The 
needed  process  changes  cannot  be  achieved  by  merely  nibbling  around  the  edges.  An  integrated,  systematic 
revamping  is  needed,  lest  the  individual  function  operate  at  cross  purposes. 

Principal  needs  begin  with  demanding  the  OS  attributes  in  the  Requirements  process,  institutionalizing  enabling 
program  management  approaches,  source  selection  and  contracting,  a  new  test  and  evaluation  philosophy,  and  the 
entire  acquisition  infrastructure  from  the  Hill  and  OMB  through  OSD  and  the  Services' to  the  Materiel  Commands; 
and  the  management  tools  provided  and  imposed  upon  program  managers.  Key  areas  are  addressed  in  the 
following  charts  and  specific  remedial  actions  are  recommended. 
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Revamping  the  Management  and  Oversight  Process 

-  Changing  the  Way  We  Think  and  Do  Business  - 


•  Traditional  Program  Manager’s  mantra:  Change  is  an  enemy 

“Baseline  to  point  solutions;  shoot  anyone  who  wants  to  change  anything” 


•  Static  solutions  to  dynamic  world 

-  Freeze  and  develop, 

-  Freeze  and  test, 

-  Freeze  and  produce 


•  Traditional  way  doesn’t  work  any  more ...  the  world  is  change 


The  process  conflict  arises  from  greatly  shortened  technology  cycle  times 
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The  existing  DoD  processes  for  systems  acquisition  derives  from  an  essentially  static  view  of  technology,  external 
demands,  and  system  configurations.  The  historic  framework  assumed  that  change  was  largely  elective  and  the  result 
of  a  DoD-controlled  process  ~  an  Engineering  Change  Proposal,  for  example.  This  static  view  permeates  the 
requirements  community,  the  FAR,  the  acquisition  process,  and  review  and  oversight  at  all  levels.  It  is  reflected  in 
detail-based  design  review  exit  criteria,  delivery  of  detailed  specifications  and  build-to-print  drawings,  physical 
configuration  audits,  maintaining,  government-approved  parts  lists,  and  so  on.  DoD-based  support  concepts  were 
even  less  agile. 

While  numerous  acquisition  reform  efforts  have  had  some  success  at  streamlining  this  process,  the  cycle  time 
revolution  in  electronics  technology  has  rendered  this  static  model  obsolete  and  dysfunctional.  Today,  the  technology 
available  at  design  time  may  be  obsolete  and  unavailable  at  reasonable  prices  when  it  is  time  to  build  qualification 
articles,  and  again  at  the  time  of  building  the  IOT&E  articles,  and  yet  again  for  initial  production,  and  the  cycle 
continues  throughout  the  fielded  life  of  the  system.  Simply  put,  the  technology  cycle  time  is  inside  the  response  loop 
of  the  classical  DoD  process. 

The  prevailing  DoD  situation  is  illustrated  by  the  graphic  above  which  plots  technology  cycle  time  against  the  agility 
of  the  acquisition  system.  Currently  DoD  tends  to  operate  near  the  origin  with  a  static-oriented  acquisition  approach 
that  presumes  a  relatively  static  technology  cycle  rate.  Legacy  systems,  configured  -according  to  the  more  static 
model,  are  caught  in  a  high  cycle  rate  world  and  fare  poorly.  The  objective  is  to  move  to  the  upper  right  hand  comer 
with  responsive  acquisition  and  support  processes. 
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Requirements 

-  Demanding  OS  Attributes  as  Mission  Critical  - 

•  When  challenging  dead  end  architectures  and  technologies,  a  frequent  reply  is:  .  .under 
intense  scrutiny,  absolute  requirement  to  minimize  cost  and  risk” 

•  Severely  disincentivizes  investment  beyond  the  minimum  immediate  need  -  all  potential 
outcomes  for  Program  Manager  are  downside,  little  upside  reward: 

-  “We  have  dead-end,  stovepipe  systems  because  we  disincent  anything  more” 

-  The  most  powerful  incentive  for  the  OS  Process  is  to  correct  the  disincentives 

•  Requirements  need  to  demand: 

-  Plug  &  Fight/Play  in  favor  of  the  last  increment  of  individual  performance 

-  Configurations  which  will  be  viable  in  the  long  run,  staying  abreast  of: 

•  Evolving  force  and  operational  needs 

*  Realities  of  budget,  technology,  and  supplier  availability 

-  Robust  migration  path 

•  Facilitate  reuse  of  new  work  by  others  (documentation,  transfer  assistance,  etc.) 


Requirements  need  to  demand: 

-  OS  Process  attributes  of  Plug  &  Fight/Play  and  COTS  affordability 

-  System  configurations  and  robust  migration  plans  for  life  long  viability 


The  traditional  requirements  process  needs  to  be  changed  to  recognize  the  operational  imperative  of  Open  Systems 
attributes.  If  the  OSTF  is  correct  and  future  operational  concepts  cannot  be  achieved  absent  a  rigorous  Open 
Systems  Process,  then  the  OS  Process  is  not  just  an  acquisition  issue. 

The  recommended  OS  attributes  are  so  vital  as  to  be  mission  critical 

The  operational  community  cannot,  given  the  current  and  projected  low  budgets,  afford  to  have  investment  funds 
spent  which  do  not  return  a  quantum  increase  in  operational  effectiveness.  In  the  current  environment  the  ability  to 
innovate  and  integrate  forces  as  needed  at  the  moment,  and  the  capacity  of  systems  to  stay  viable,  is  operationally 
more  important  than  the  last  increment  of  individual  performance. 

When  the  continued  use  of  dead-end,  stovepiped  architectures  and  technologies  is  challenged,  a  frequent  response  is 
that  the  requirements  demand  nothing  more.  Most  Program  Managers  are  severely  disincentivized  against  incurring 
cost  or  schedule  risk  for  anything  more  then  the  minimum  immediate  requirement,  and  there  is  little  or  no  upside 
reward  for  enabling  long-term  viability.  Today,  obsolescence,  difficulties  integrating  with  the  force,  and 
unaffordability  are  more  effective  threats  to  systems  than  enemy  action. 

By  the  nature  of  the  DoD  acquisition  process,  this  situation  can  not  be  significantly  corrected  without  a  requirements 
demand  for  the  OS  Process  attributes.  Requirements  must  demand  the  benefits  of  Plug  &  Fight/Play,  COTS 
affordability,  and  system  configurations  and  robust  migration  plans  to  enable  long-term  system  viability. 

The  operations  community  is  stuck  with  dead-end,  stovepiped  systems  which  are  support  nightmares  and  risk  critical 
missions  because,  in  part,  the  formal  requirements  process  demand  little  more  than  that. 
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Core  Mindset  for  Program  Management 

-  OS  Process  Must  Permeate  Whole  Structure  - 

•  At  the  Program  level,  OS  Process  will  become  a  survival  core  value 

•  System  solutions  start  with  understanding  the  problem  to  be  solved 

-  System  definition  phase  must  include  a  Viability  Risk  Analysis  and  required  interfaces  with  related 
architectures 

-  OS-compatible  analysis  tools  should  be  accessed  -  partitioning,  cost,  technology  and  obsolescence 
projection,  etc. 

•  Architecture-driven  modularity  developed  in  system  engineering  process  enables  Plug  &  Play 
HW  and  SW,  and  reuse  --  minimizes  constant  regression  testing 

•  OS  Process  attributes  and  robust  migration  plans  demonstrated  in  System  Concept  Definition 
and  intergrated  into  Performance  Specifications 

•  Management  processes  nurture  natural  cycle  rates  of  components  and  interfaces 

•  Enabling  Program  Management  infrastructure  also  demonstrated;  for  example: 

-  Acquisition  plan,  review  processes,  and  criteria 

-  Architectural  Control  Board  (ACB)  and  compliant  architecture  hierarchy 

-  Contracting  and  Source  Selection  criteria 

-  Test,  product  support,  training 

-  Diminishing  supplier  program 

Must  permeate  entire  acquisition  management  processes. 

Source  Selection  criteria,  and  milestone  and  upgrade  reviews 
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OS  Process  attributes  are  rapidly  becoming  requisite  for  the  survival  of  programs.  Programmatic  threats  were 
discussed  in  the  viability  risk  analysis.  Given  the  current  era  and  the  worsening  budget  environment,  many 
programs  are  a  higher  risk  from  programmatic  actions  than  from  enemy  action.  An  OS  Process  must  permeate 
DoD  management  processes,  Source  Selection  criteria,  and  formal  Milestone  and  upgrade  reviews. 

With  increasingly  prolonged  acquisition  cycles,  technology  is  often  obsolete  several  generations  before  EMD  is 
complete,  much  less  before  fielding  of  the  weapons  system.  The  result  is  increased  cost  and  time  to  mitigate  the 
effects  of  technology  and  parts  obsolescence.  The  operating  efficiency  of  the  rest  of  the  force  structure  is  often 
jeopardized,  and  fielding  is  even  later  than  planned  —  often  due  to  attempts  to  avoid  rising  costs  on  a  near  term 
basis  --  by  stretching  the  development  program. 

An  OS  Process  brings  with  it  other  characteristics  to  provide  program  management  tools  and  to  mitigate  the 
pitfalls  of  business  as  usual.  These  are: 

(1)  Robust  mitigation  plans  to  keep  the  technology  and  design  fresh,  providing  a  matrix  of  anticipated  changes 
and  resulting  configurations  referenced  to  program  milestones; 

(2)  Early  commitment  and  demonstration  to  the  foundations  and  definition  of  the  architecture,  modularity,  and 
flexibility; 

(3)  Formal  processes  for  forecasting  change  and  synchronizing  likely  high  cycle  rates  with  other  change  cycle 
levels  for  remaining  tiers  of  the  weapons  system,  and  for  temporally  pegging  them  to  program  milestones 
reviews; 

(4)  Modification  of  normal  definition  of  exit  criteria  at  CDR,  PDR,  or  any  program  milestones  reviews  to 
reflect  the  upgrade  or  refresh  plan,  based  upon  maintaining  Form,  Fit,  Function,  and  Interface  (F3I) 
discipline. 
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(5)  Use  of  an  Architecture  Control  Board  process  to  ensure  compliance  and  conformance;  and 

(6)  Make  OS  attributes  a  primary  Source  Selection  criteria. 

The  entire  program  management  process  needs  to  be  reengineered  as  a  coordinated  asynchronous  flow, 
geared  toward  the  most  rapid  technology  turn  cycle  (also  may  be  considered  the  obsolescence  cycle)  across 
the  full  life  of  the  program:  requirements  definition,  development,  T&E,  production,  and  support.  System 
level  specification  need  to  be  functional  as  in  the  Performance  Based  Business  Environment.  Formal 
definition  of  exit  criteria  for  key  program  milestones  such  as  PDR  and  CDR  should  be  modified  to  reflect 
an  F3I  structure  and  Migration  Plan. 
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Contracting  and  Source  Selection 

-  Encourage  OS  Processes  - 

•  Revamp  the  FAR 

-  Natural  extension  of  Performance  Based  Business  Environment  (PBBE)  already  started 

-  Eliminate  regulated  obstacles  to  OS  Process 

-  Impose  architectural  hierarchy  and  ACBs 

-  Align  contract  structure  with  system  architecture  (development  through  support) 

-  Make  OS  Process  a  required  Source  Selection  Criteria 

•  Reorient  Specifications  and  Interface  Control  Documents 

-  Specify  and  baseline  system-level  functionality  (PBBE)  and  H  (OS)  interface  control 

-  Manage  high  cycle-rate  functions  to  PI  and  mitigation  plans 

•  Contractors  and  suppliers  have  lower  tier  configuration  control  within  B  discipline 

•  Abandon  build-to-print  process  in  favor  of  interface  specifications 

•  Contractors  analyze  best  use  of  resources  across  all  criteria 

-  Implement  program  and  migration  plans  by  most  economical  process 

-  Focus  on  best  system/component/part  value 

-  Freedom  to  innovate  using  competitive  pricing 

•  Minimizes  Class  I  changes 

•  Strong  OS  Process  treatment  in  Source  Selection 


^^Foix^^^cesst^ecomeatnndustri^^Mcorecompetwicy^| 
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The  FAR,  a  product  of  the  historic  static  perspective  of  the  world,  presents  a  number  of  impediments  to  an  OS 
Process  and,  not  surprisingly,  does  not  capture  opportunities  to  be  constructive  in  this  context.  Renovation  is 
underway  to  implement  PBBE,  an  underlying  assumption  of  the  suggested  OS  Process. 

The  PBBE-like  renovation  should  be  extended  to  put  into  place  some  of  the  foundations  of  an  effective  OS 
Process  and  remove  impediments.  Example  measures  include  recognition  of  the  necessity  for  a  hierarchy  of 
architectures  and  accompanying  Architectural  Control  Boards,  and  establishment  of  an  interlocked  hierarchy 
between  the  Government  Program  Office,  Prime  Contractor,  Subcontractors  and  Suppliers.  The  FAR  should 
recognize  that  contract  structures  need  to  be  aligned  with  the  structure  of  the  system  architectural  hierarchy.  The 
necessity  for  tailored  management  of  high-cycle  rate  elements  would  be  reflected  in  system  definition  and 
baselining  in  terms  of  functional  PBBE-based  specifications,  the  system  architecture,  and  F3I  interface  control 
documents  controlled  by  the  hierarchy  of  ACBs,  and  mitigation  plans  to  assure  and  enable  life-long  system 
viability.  Review  and  oversight  criteria  organized  around  the  build-to-print  perspective  would  be  abandoned. 

The  hierarchical  ACB  structure  is  essential  to  maintain  F3I  discipline  while  passing  control  of  lower  tier  detailed 
configurations  to  contractors  and  suppliers.  This  approach  offers  the  potential  for  increased  competition  at  each 
lower  tier,  significant  cost  and  schedule  improvement,  refreshed  technology,  and  a  continuing  supplier  base. 

The  ability  of  the  government  and  contractors  to  implement  migration  plans,  seek  the  most  economical  processes, 
focus  on  best  value,  and  have  the  freedom  to  innovate  using  competitive  prices  is -all  enhanced.  Properly 
constructed,  this  approach  appears  to  offer  the  ability  to  dramatically  reduce  the  need  for  Class  I  changes  to  the 
weapon  system  and  the  attendant  requal  costs.  However,  the  prOS  Processective  gains  can  be  foiled  by  trying  to 
accomplish  the  objectives  without  addressing  cultural  changes  in  the  acquisition  and  test  communities. 
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Test  and  Evaluation 

-  New  Philosophy:  Validate  Functional  Performance  and  F3I  Provisions  - 

Many  interviewees  consider  current  test  practice  a  crippling  OS  Process  impediment 

•  Test  philosophy  must  acknowledge  that  configurations  are  temporal  —  they  cannot  pre¬ 
exist  or  endure 

-  IOC  configuration  cannot  pre-exist  at  OPEVAL 

-  OPEVAL  configuration  cannot  pre-exist  at  qual  test 

-  Configurations  probably  not  even  constant  across  test  units 

-  Product  support  must  deal  with  continually  evolving  configurations 

•  Early  functional  testing  may  have  to  use  surrogate  hosts 

•  Must  reengineer  test  flow  to  test  functionality,  PI,  and  migration  path  early, 
then  balance  other  test  needs  with  reality  of  evolving  product  configurations 

•  Avoid  full  duplication  of  tests  between  configurations,  contractor,  government 

(ex.  Software  regression  testing  is  usually  very  expensive  and  often  unnecessarily  duplicative) 

•  Testing  must  be  tailored  to  the  phase  of  evolution  of  the  product  requirements 


Must  revamp  test  objectives,  philosophy,  criteria; 
Need  demonstration  programs 

KV19/9U  1415 
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IOT&E  was  frequently  cited  as  an  major  OS  Process  stumbling  block. 

The  basic  philosophy  of  weapon  systems  testing  must  be  revamped.  Current  focus  is  on  validating  the  “final 
configuration”  which  will  go  to  production.  Test  philosophy  needs  to  acknowledge  that  the  natural  cycle  rate  of 
some  technologies  is  less  than  the  test  period  and  certainly  less  than  the  time  from  design  to  initial  production.  In 
many  cases,  components  which  should  be  used  in  production  will  not  have  been  invented  yet  at  the  time  fabrication 
starts  on  the  OT&E  test  articles.  Clearly  it  is  time  to  rethink  DoD  test  objectives,  philosophy,  and  test  planning. 

Today  the  factors  most  important  for  weapon  system  effectiveness  are  functional  capabilities  and  the  ability  to  stay 
viable  by  many  criteria.  So  this  is  what  testing  should  validate.  Early  testing  should  focus  upon  operational  and 
support  functionality,  the  robustness  of  the  architecture-driven  modularity,  and  long-term  migration  planning.  As 
the  design  matures,  testing  should  address  the  adequacy  of  the  F3I  specifications  and  the  expected  implementation 
of  the  interfacing  assemblies.  While  the  current  implementation  of  an  assembly  may  be  tested  to  help  assess  the 
adequacy  of  a  F3I  specification  at  the  system  level,  it  is  more  the  specification  which  is  being  validated  rather  than 
the  particular  implementation  of  the  assembly.  Assuring  assembly  compliance  with  the  F3I  specification  is  usually 
not  a  system  level  test  issue. 

If  quality  modularity  and  reuse  is  achieved,  then  duplicative  testing  should  be  addressed  —  particularly  software 
regression  testing,  which  is  currently  enormously  expensive  for  DoD. 

Since  legacy  systems  are  particularly  a  problem,  the  OSTF  suggests  a  series  of  demonstration  projects  be 
conducted,  using  legacy  systems  that  are  candidate  for  technology  refresh,  to  help  develop  a  revised  test  policy. 
Emphasis  should  be  on  three  issues:  1)  how  to  synchronize  technology  insertion  and  functional  testing;  2) 
reductions  in  test  personnel  and  time  allocations;  and,  3)  metrics  to  capture  the  cost  savings  for  both  insertion  and 
testing. 
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Funding 

-  Current  Practice  Causing  Serious  Difficulties  - 

•  Maintaining  system  viability  requires  overall  life  cycle  Responsibility,  Authorities,  and 
Accountabilities  (RAA) 

-  PMs  generally  have  life  cycle  responsibilities,  but  neither  authorities  nor  resources 

-  Let  PMs  balance  the  pain  between  NRE  and  recurring  O&M 

-  Assign  PM’s  total  life  cycle  RAA 

•  Colors -of-Money  (RDT&Evs.  Production  vs  O&S)  inhibit  effective  technology  renewal 

-  For  high-cycle-rate  elements,  problems  and  their  solutions  extend  across  color  boundaries 

-  Support  problems  just  as  bad  in  R&D  and  Production  phases 

-  Need  relief  to  allow  technology  renewal  with  any  color-of-$$  available 


•  Funding  need  changes  are  very  difficult  for  most  programs 

-  Changes  mostly  accumulate  until  major  system  upgrades;  often  involve  expensive  platform  mod 

-  Changes  plus  mod  cost  difficult  to  fund;  jeopardizes  program 

-  OS  Process  could  spread  changes,  avoid  many  mods;  funding  more  likely 


OS  attributes  usually  reduce  costs  for  all  phases  of  programs,  and  can  be  readily  included  in  new  systems.  In  the 
new,  high  technology  turnover  work,  the  restrictions  accompanying  distinctions  between  the  various  program 
phases  are  dysfunctional  to  the  point  of  crippling  programs.  The  foil  life  cycle  needs  to  be  managed  as  an 
integrated  whole.  For  the  most  part,  program  managers  have  such  responsibility,  but  insufficient  authority  and 
resources.  Program  managers  need  to  be  vested  with  the  foil  authorities  and  unfettered  resources  necessary  to 
seamlessly  manage  the  system  life  cycle. 

Current  color-of-money  restrictions  are  enormously  crippling.  This  situation  has  been  the  subject  of  the  DSB  and 
DoD  work  and  is  well  understood.  Color-of-money  restrictions  will  also  significantly  impede  OS  attributes, 
further  adding  to  the  urgent  need  for  correction. 

While  defense  funding  overall  has  declined,  operations,  support,  and  modernization  costs  continue  to  mount. 
Forces  are  reduced  and  the  investment  accounts  are  often  billpayers,  further  reducing  modernization.  As  systems 
and  parts  rapidly  become  obsolete,  they  need  to  be  upgraded  to  stay  viable.  But  because  of  the  lack  of  F3I 
compatibility  —  hardware  to  hardware,  software  to  software,  and  hardware  to  software  --  the  ability  to  change  by 
simply  upgrading  the  technology  without  making  major  changes  to  the  weapon  system  is  virtually  non-existent. 
The  cost  --  using  today’s  culture  and  testing  “rice  bowl”  mentality  —  is  often  prohibitive  and  the  budget  often 
unavailable.  Absent  architecture-driven  modularity,  components,  assemblies,  and  subsystem  —  displays,  comms, 
processing  —  must  often  be  extensively  modified  and  requalified.  A  major  mod  cycle  is  required.  As  a  result, 
needed  subsystem  upgrades  accumulate,  more  components  become  obsolete,  and  the  system  rapidly  loses 
viability,  putting  the  operational  mission  in  jeopardy.  This  downward  spiral  is  being  replicated  throughout  DoD. 
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Incorporation  of  an  OS  Process  can  provide  major  relief  for  this  situation,  if  considered  early  enough  in  the  process,  and  if 
combined  with  an  plan  to  incorporate  technology  in  frequent  and  timely  reasonable  increments,  compatible  with  F3I 
discipline.  With  good  architecture-driven  modularity,  components,  assemblies,  and  subsystems  are  effectively  isolated  from 
each  other  and  can  be  refreshed  at  their  natural  rates.  A  mod  cycle  can  be  modest,  if  needed  at  all.  Upgrades  can  be  inserted 
as  they  are  available,  funding  strangulation  can  be  avoided,  and  systems  can  remain  significantly  more  viable  in  all 
dimensions:  operations,  funding,  technology  currency,  and  mission  effectiveness.  DoD’s  continued  reliance  on  legacy 
systems  becomes  considerably  more  feasible. 
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Infrastructure  Needs 

•  Tools  for  program  planning,  cost  modeling,  budgeting,  sustainment 

-  Planning  tools  incorporating  high  cycle  effects  and  OS  effects  are  immature 

-  Couldn’t  find  cost  estimating  tools  --  some  being  started 

•  Acquisition  processes  need  to  be  reengineered  from  PDRR  through  Support 

-  Strong  disciplined  systems  engineering  essential;  grow  competency  by  multiples 

-  Decrease  component  design  and  test  engineering 

-  Develop  management  and  integration  techniques  to  marry  low  cycle  change  elements  with 
high  cycle  change  elements  later  in  process 

-  Confirm  HW  &  SW  structure  very  early  —  before  application  development 

-  New  functional  validation  and  design  review  exit  criteria 

-  Test  philosophy:  Minimize  duplication,  qualify  SW  early,  qualify  HW  late,  update  SW 
always 

•  Currently  training  is  very  limited 

-  Not  a  curriculum  topic  in  DoD  professional  schools 

-  Acquisition  and  logistics  workforce  not  trained  to  PBBE  and  OS  Process 

-  Functional  and  interface  discipline  vs.  “how-to”  and  “build-to-print”  specs 


Three  major  elements  of  the  infrastructure  need  to  be  addressed  to  facilitate  incorporation  of  an  OS  Process: 
Financial  and  Planning  tools,  the  Acquisition  Process  itself,  and  Training.  Cost  modeling  and  budgeting  tools  need 
to  be  addressed  for  functional  requirements  and  life  cycle  effects.  Cost  estimating  relationships  are  virtually  non¬ 
existent  when  viewed  in  the  context  of  the  significant  process  changes  advocated,  covering  development,  test  and 
evaluation,  incorporation  into  product,  and  sustainment.  In  the  same  vein,  planning  tools  need  to  be  developed, 
along  with  the  cost  relationships,  considering  high  cycle-rate  technology  introduction  using  the  rubric  of  F3I.  For 
the  life  cycle,  tools  need  to  be  developed  to  quantify  the  advantages  of  frequent  technology  renewal  by  the  OEM 
instead  of  continuing  build-to-print  of  obsolete  parts. 

The  Acquisition  Process  needs  to  be  reengineered  from  development  through  sustainment  in  order  to  take 
advantage  of  the  anticipated  saving  offered  by  incorporation  of  an  OS  Process.  F3I  and  substantial  changes  from 
traditional  configuration  management  are  critical  to  successful  implementation  of  the  OS  Process.  This  creates  a 
demand  for  strong,  disciplined  systems  engineering.  As  a  consequence,  systems  engineering  needs  are  projected  to 
grow  by  multiples,  while  detailed  design  engineering  needs  should  decrease  by  greater  multiples.  An  OS  modular 
and  portability  concept  needs  to  be  institutionalized,  including  the  synchronization  of  changes  from  high  cycle-rate 
technology  turnover.  COTS  approaches  for  software  development  must  be  included.  Configuration  definition 
needs  to  account  for  those  elements  likely  to  remain  stable  over  the  life  cycle  and  those  subject  to  frequent  change. 
Functional  validation  and  design  review  exit  criteria  need  to  be  established  accordingly,  along  with  a  test  and 
evaluation  philosophy  reflecting  definition  of  a  temporal,  rather  than  a  final,  configuration. 

There  is  a  significant  shortfall  of  personnel  in  the  acquisition  workforce  and  logistics  infrastructure  who  are  trained 
in  the  PBBE  and  the  OS  environments.  Yet,  it  is  these  two  groups  who  are  perhaps  the  most  critical  to  successful 
implementation  and  can  prove  to  be  the  greatest  impediment  to  success. 
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Industrial  Base 

DoD-centric  analysis  argues  strongly  for  imposing  extensive  OS  requirements  — 
need  to  consider  impact  on  industrial  base 

•  Business  basics  require  that  investment  be  recovered  and  profit  made 

•  Impact  of  imposing  OS  requirements  on  industry 

-  OS  greatly  reduces  non-recuiring  and  recurring  cost,  which  equals  less  profit/win 

-  Few  new  starts  and  upgrades  =  less  wins 

-  OS  reduces  banier-to-entry;  harder  to  assure  future  business 

-  Incentive  for  unique  investment  drastically  reduced 

-  Primes  significantly  disincentivized  for  OS  Process  unless  business  is  at  severe  risk 

•  Lower  tiers  greater  than  ~  75%  systems  cost 

-  Face  primes’  problems  +  primes  vertically  integrating  and  influencing  buy  decisions 

-  Lower  tier  unstable;  caught  between  economics  of  DoD,  primes,  and  commercial 

-  Much  OS  use  in  the  lower  tiers 

•  Pressures  are  driving  DoD  to  become  more  involved  in  the  lower  tiers 


Industry  will  follow  if  necessary,  but  not  their  choice  — 

Recommend  that  DoD  cause  a  detailed  investigation  of 
lower  tier  market  dynamics  and  economics 
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The  urgent  needs  of  DoD  and  the  potential  enormous  benefits  of  OS  argue  strongly  for  extensive  adoption  of  an  OS 
Process.  The  OSTF  has  some  observations  concerning  the  impact  on  the  defense  industrial  base,  a  cornerstone  of 
any  implementation  of  an  OS  Process. 

The  fundamentals  of  business  in  the  U.S.  require  that  investments  be  recovered  and  profits  be  made.  Our  system  is 
generally  self-enforcing  --  inadequate  performers  eventually  fail. 

In  the  commercial  market.  Openness  generally  fosters  overall  market  growth  and  permits  minority  player 
participation.  For  example,  accessible  operating  system  interfaces  have  enabled  a  vast  application  program 
industry,  which  in  turn  has  fostered  an  overall  PC  market  which  is  many  orders  of  magnitude  larger  than  would 
have  occurred  without  Open  interfaces.  It  is  instructive  to  note  that  major  firms  like  Microsoft  depended  heavily  on 
Openness  for  initial  market  entry  and  then,  once  established,  adopted  more  restrictive  strategies. 

The  “market  growth”  dynamic  does  not  generally  exist  in  today’s  defense  market:  the  total  DoD  budget  is 
essentially  fixed  and  there  is  little  opportunity  for  the  industrial  base  to  influence  the  allocation  between  investment 
and  the  other  accounts;  there  are  few  new  starts.  In  aggregate,  these  dynamics  create  in  large  incumbent 
contractors  a  massive  disincentive  to  change  the  status  quo.  They  will  see  as  the  primary  effect  of  OS  the  spreading 
of  the  limited  funds  across  even  more  contractors,  which  will  reduce  margins  and  earnings.  For  these  contractors, 
significant  incentive  to  adopt  an  OS  Process  exists  only  when  a  program  is  at  great  risk,'  particularly  if  unaffordable. 
(IEWCS,  JSF,  and  perhaps  the  BSY-2  replacement  are  good  examples  —  conventional  approaches  could  not  have 
been  funded  in  the  current  budget  environment.) 

Non-incumbent  contractors  may  be  more  receptive  to  the  OS  Process,  since  OS  Processes  can  lower  barriers  to 
entry  and  offer  increased  opportunities. 
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These  are  probably  the  central  dynamics  behind  the  OS  successes  which  we  have  seen  in  DoD.  Profitability  is 
down  compared  to  a  conventional  approach,  but  a  lower  profit  program  is  apparently  better  than  no  program. 

This  dynamic  arguably  serves  both  the  industrial  base  and  DoD  well.  Programs  based  on  OS  Processes  are  alive, 
healthy,  and  well  postured  for  an  uncertain  future;  and  the  industrial  base  is  sustained.  The  summary  of  the 
Lockheed  Martin  Navy  Systems  Program  Office  in  Manassas  after  aggressively  adopting  an  OS  approach  to  the 
BSY-2  replacement  is  instructive.  Good  as  their  traditional  products  were,  they  were  unaffordable  in  the  current 
budget  environment  and  the  business  was  in  extremis.  The  Program  Office  took  the  controversial  approach  of 
organizing  around  an  OS  strategy  and  now  feel  that  they  have  the  best  system  in  the  world.  Apparently  their  U.S. 
and  allied  customers  agree,  for  their  win  rate  has  been  unprecedented.  But  they  feel  competitively  vulnerable  with 
the  OS  architecture  and  continue  to  strive  aggressively  to  offer  customers  the  very  best  value.  They  have  done  as 
well  in  the  new  budget  environment  as  they  could  have  and  they  are  healthy.  This  seems  a  noteworthy  model  for 
the  future  and  well  worth  pursuing. 

The  situation  at  the  lower  tiers,  representing  about  75%  of  system  cost,  is  more  complex  and  only  marginally  stable. 
They  face  most  of  the  problems  of  the  primes  and,  additionally,  are  caught  in  a  pinch  between  consolidating  primes 
who  are  also  becoming  more  vertically  integrated,  and  the  expanding  use  of  COTS.  There  is  increasing  concern  for 
maintaining  genuine  competition  and  a  viable  industrial  base.  Some  of  the  most  extensive  use  of  OS  approaches 
occurs  in  die  lower  tiers  and  that  can  only  increase. 

Pressures  are  driving  DoD  to  become  more  involved  in  the  lower  tiers  of  the  defense  industrial  base.  The  OSTF 
recommends  that  DoD  cause  a  detailed  investigation  of  lower  tier  market  dynamics  and  economics  to  occur. 
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Pilot  Program  Candidates 

There  are  several  programs  which  would  be  good  candidates  to  be  designated  pilot  programs 
for  pathfinding  implementation  of  an  OS  Process: 

-  National  Missile  Defense 

•  Mission  is  to  achieve  and  maintain  a  deployment  ready  posture  until  a  deployment  decision  is 
made,  with  continuous  rolling  technology  insertion  program 

•  Largely  a  System-of-Systems,  dependent  upon  other,  evolving  systems  not  subordinate  to  the 
program  office;  dependent  upon  an  architecture-driven  modularity  approach;  long-term  viability 
will  be  a  particular  problem 

•  Newly  appointed  Lead  System  Integrator  with  good  OS  perspective  and  implementation 
capabilities;  good  chance  of  OS  Process  success 

-  Theater  Air  and  Missile  Defense 

•  Mission  is  to  establish  and  maintain  interoperability  between  a  host  of  service  surveillance, 
battle  management,  and  weapons  programs  to  achieve  an  integrated  trans-DoD  capability 

•  Almost  entirely  a  System-of-Systems,  dependent  upon  other,  evolving  systems  non-subordinate 
to  the  program  office;  dependent  upon  an  architecture-driven  modularity  approach 

•  Requirements  and  CONOPS  responsibility  rest  with  JTAMDO  and  engineering  with  BMDO. 
Lead  system  engineering  responsibility  for  implementation  not  yet  established.  Excellent 
application  of  OS  Process  early  enough  in  process 

-  Joint  Tactical  Radio 

•  Excellent  front-end  effort  but  no  real  implementation  program  yet;  would  be  an  excellent 
application  of  an  OS  Process  early  enough  in  process 


USD(A&T)  should  designate  several  major  programs  with  extraordinary  need  for  OS  attributes  as  pathfinder  programs  for 
implementing  the  OS  Process.  Candidate  programs  include  NMD,  JTAMD  and  JTRS.  These  pathfinders  are  supportive  of 
JV2010  and  should  immediately  provide  a  significant  driving  force  for  launching  the  OS  Process  as  the  preferred  method 
of  systems  acquisition.  The  business  case  for  selecting  these  programs  as  OS  Process  pathfinder  programs  is  based  on  the 
following  reasons: 

(1)  Interoperability  and  Dominant  Maneuver:  Continuous,  uninterrupted  flow  and  processing  of  information  among  the 
many  fundamental  building  blocks  (e.g.,  Ground  Based  Interceptor,  Space-Based  Infrared  Systems,  THAAD 
Battery,  and  Wide-band  Networked  Radios)  of  these  sophisticated  systems  is  essential  for  dominant  maneuver,  real 
time,  and  effective  operations.  Adherence  to  Open  standards  is  needed  to  achieve  interoperability  among  systems 
and  subsystems  comprising  each  of  these  pathfinder  systems. 

(2)  Integratability:  No  single  system  can  perform  the  entire  JTAMD  or  NMD  mission.  There  is  a  strong  need  for  a 
system-of-systems  approach  to  achieve  integratability  of  lower  and  upper  tier  systems,  and  integration  of  joint 
Forces  to  exploit  land,  sea,  and  air  combat  capabilities.  The  JTRS  will  also  require  integratability  at  different  Force 
levels,  and  integration  within  and  among  Services  and  allies. 

(3)  Long-Term  Viability:  The  strong  dependence  on  state-of-the-art  technologies  by  these  systems  demands  flexibility 
to  respond  to  evolving  and  more  advanced  threats,  and  the  capability  to  rapidly  insert  new  technology  in  real  and 
near  real  time.  As  the  key  nugget  of  the  OS  Process,  architecture-driven  modularity  is  the  best  guarantee  for  access 
to  latest  commercial  technology  and  continuous  viability  of  these  systems. 

(4)  Affordability  and  Supportability:  These  pathfinder  programs  lend  themselves  to  the  architecture-driven  modularity, 
software  reuse  and  portability,  and  hardware  commonality  features  of  OS.  These  features  are  essential  for  creating 
economies  of  scale  to  minimize  operations  and  support  costs,  facilitate  repair  and  maintenance,  and  ensure  access  to 
multiple  sources  of  supplies  throughout  the  entire  life  cycle  of  each  system.  DoD  must  leverage  the  investment 
made  by  other  federal  agencies  and  the  commercial  industry  in  technology,  products,  and  processes  relevant  to  these 
systems  to  reduce  the  total  ownership  cost  and  maximize  supportability  of  each  system. 
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Incentives 

and 

Disincentives 
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OS  Process  Implementation  Challenges 


Should  Be  Easy _ Will  be  Tough 


OS  Process  is  a  mindset  for  architecting 

Our  processes  are  dysfunctional  obstacles 

•  We  already  architect  Forces,  systems,  and 

•  Geared  for  static  programs  in  a  static  world 

processes 

•  “Freeze  &  build” 

•  We  already  use  configuration  control  processes 

•  Phobic  to  managing  change;  ex: 

•  OS  Process  is  just  an  additional  criteria 

•  Budgeting  criteria 

•  There  are  industry  and  DoD  role  models 

•  Acquisition  milestones 

•  Some  programs  motivated  as  survival  issue: 

•  Parts/technology  refresh  $$ 

“cheaper,  better,  faster”  can  save  programs 
•  We  should  be  doing  it  anyhow 

Implementing  OS  Process  is  an  institutional  matter 
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The  challenge  of  implementing  an  OS  Process  is  not  so  much  about  technology  as  it  is  about  influencing  the  program 
managers  and  other  acquisition  practitioners  to  think  in  terms  of  configuring  systems  for  constant  evolution  in  a  dynamic 
world.  We  already  do  many  of  the  things  needed  to  implement  an  OS  Process  such  as  architecting  forces,  systems,  and 
processes.  In  addition,  the  realities  of  fiscal  pressures  and  industry  practices  are  moving  some  programs  to  an  OS  Process 
as  a  matter  of  survival.  However,  our  institutional  processes  are  holding  back  our  program  managers  and  other 
acquisition  practitioners  from  doing  what  it  is  they  should  be  doing  anyhow.  Artificial  milestones,  constrictive  budgeting 
rules,  and  lack  of  support  and  funding  for  evolutionary  technology  refresh,  are  significant  disincentives  and  barriers  to 
managing  change  in  an  institutional  process  created  to  produce  static  programs  for  a  static  world  that  bears  no 
resemblance  to  reality.  OSD  and  Service  leaders  must  clearly  and  strongly  champion  Plug  &  Fight/Plug  &  Play  to 
successfully  enable  our  acquisition  practitioners  to  implement  an  OS  Process.  This  support  by  the  senior  leaders  needs  to 
be  visible  and  sustained  if  the  institutional  obstacles  are  to  be  overcome. 
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Incentives 

•  We  have  smart  people  who  want  to  do  a  good  job;  we  need  to  ... 

-  Remove  the  impediments  and  disincentives 

-  Set  objectives  and  boundaries 

-  Include  OS  achievement  as  a  specific  job  expectation 

-  Evaluate  commercial  incentive  practices 

-  Reward  OS  successes 

•  High  visibility  recognition  by  Leadership 

-  Tolerate  thoughtful  mistakes 

-  Get  out  of  the  way 

Commit  to  removing  the  impediments,  recognize  successes, 

Get  out  of  the  way 


A  large  majority  of  respondents  to  the  OS-JTF  survey  regard  lack  of  real  incentives  as  a  major  obstacle  to  OS 
implementation.  The  DoD  constituencies  responsible  for  Plug  &  Fight/Play  are  motivated  by  different  kinds  of  incentives 
and  rewards.  Some  may  be  motivated  by  intrinsic  rewards  and  incentives  such  as  strong  personal  drive  and  achievement, 
and  will  find  innovative  ways  to  overcome  to  obstacles  (i.e.,  disincentives).  Others  will  adopt  OS  only  when  they  are 
provided  with  extrinsic  rewards  and  incentives,  and  only  after  the  Services,  components,  or  the  senior  DoD  leadership 
remove  the  disincentives. 

DoD  must  clarify  OS  Process  expectations  and  delineate  boundaries  of  actions  for  those  responsible  for  implementation. 
All  DoD  constituencies  who  are  in  one  way  or  another  influencing  decisions  regarding  weapons  systems  procurement  and 
application,  or  are  being  impacted  by  the  OS  Process,  must  share  a  common  understanding  of  the  concept,  advantages,  and 
requirements  for  Plug  &  Fight/Play. 

About  one  third  of  the  respondents  to  the  OS-JTF  study  reported  that  they  are  not  aware  of  OS  and  do  not  adequately 
understand  OS.  One  third  of  the  respondents  also  consider  OS  to  be  a  short-lived  initiative.  Extensive  use  of  OS  requires 
that  all  DoD  constituencies  become  aware  of  the  OS  concept  and  have  a  shared  view  of  OS  advantages  and  requirements. 
They  must  reach  a  common  conclusion  that  the  OS  Process  is  not  another  short-lived  DoD  initiative  but  a  new  engineering 
and  business  strategy  for  fielding  superior  warfighting  capability  faster  and  more  affordably. 

The  job  description  and  the  criteria  for  performance  appraisal  and  promotion  of  the  acquisition  workforce  must  also  change 
to  reflect  the  need  for  achieving  Plug  &  Fight/Play.  DoD  must  make  achievement  of  OS  a  specific  job  expectation.  The 
acquisition  workforce  must  be  required  to  attend  Plug  &  Fight/Play  training  and  be  certified  in  OS  to  be  qualified  for 
promotion. 

To  promote  effective  implementation  of  the  OS  Process,  DoD  must  provide  incentives  to  all  its  constituencies  including 
acquisition  workforce  and  industry.  Industry  plays  a  vital  role  in  building  adaptable  technical  architectures  and  will  build 
flexibility  into  systems  if  the  requirements  call  for  it  and  proper  incentives  are  provided  for  doing  so.  DoD  must  model 
commercial  practices  in  motivation  and  distribution  of  rewards.  Creativity  and  receptiveness  to  change  must  be 
encouraged  and  thoughtful  mistakes  and  failures  tolerated.  We  must  publicize  OS  success  stories,  establish  an  OS-based 
incentive  system,  and  give  awards  for  excellence  in  OS  application.  Few  people  are  able  to  continue  a  pattern  of 
achievement  and  success  without  the  added  encouragement  provided  by  senior  leaders  recognizing  their  achievements. 
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We  must  also  remove  the  layers  of  bureaucracy  that  do  not  add  value  to  the  OS  process.  DoD  organization  structure  is 
heavily  layered  and  staff  elements  are  highly  populated.  In  order  for  each  element  of  each  layer  to  justify  its 
existence,  they  add  content,  debate,  and  delay  to  program  execution.  Guidance,  as  it  flows  down,  is  additive  rather 
than  complementary.  This  structure  is  supported  by  processes  which  are  built  around  a  short  time  horizon,  tax  dollar 
allocation  (and  reallocation  ad  infinitum),  and  management  gate-keeping  based  on  program  funding  content  rather 
than  risk  management,  capability  insertion,  and  cost  of  ownership.  These  processes  justify  the  jobs  of  a  huge  cadre 
whose  expertise  is  in  technical,  legal  and  financial  debate  rather  than  capability  delivery.  In  the  end  the  systems  are 
delivered  as  a  result  of  industrial  commitment  to  deliver  to  a  contract,  and  sheer  momentum. 
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The  Most  Crippling  Impediments 

Most  barriers  are  self-inflicted  and  entrenched 

•  Requirements 

-  We  have  stovepiped  systems  and  dead-end  technologies  because  Requirements  demand 
nothing  more  [ex:  B-2  Defensive  Avionics  8088  Processor  —  meets  requirement] 

-  If  we  want  viable,  enduring  Plug  &  Fight/Play  systems,  then  we  need  to  require  them 

•  System  management  philosophy  --  currently  “freeze  and  build” 

-  Baselining  to  the  wrong  criteria:  frozen  detailed  configurationsvs.  F3I  “sockets” 

•  Continuous  technology  refresh  throughout  entire  life  of  system 

•  Leverage  supplier  evolution  and  “cheaper,  faster,  better” 

-  Management  processes  are  phobic  and  dysfunctional  in  today’s  world 
[ex.  management,  budget,  milestone  criteria,  test,  tools] 

•  Legislation  and  regulation  [ex:  Firewalling  Dev/IOT&E/Production.  Baseline  Breach  reporting] 

-  Color-of-money  inflexibility  precludes  much  technology  refresh 

-  IOT&E  criteria:  freezes  rather  than  follows  evolving  functionality  and  evolving  product 
configurations 
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The  Plug  &  Fight,  Plug  &  Play,  and  OS  capability  requirements  must  become  key  performance  characteristics  for 
procuring  and  fielding  systems.  We  have  stovepiped  systems  and  dead-end  technologies  because  we  do  not  consider 
affordability,  flexibility,  and  upgradability  to  be  essential  system  characteristics  when  we  define  our  key  performance 
requirements.  Our  operational  performance  requirements  must  leverage  industry’s  technology  and  practices,  and 
incorporate  modularity  and  commonality  principles  to  allow  easy  maintenance  and  repair. 

Viable,  enduring,  flexible  systems  inherently  are  not  compatible  with  a  “ffeeze-and-build”  mentality.  DoD  must 
abandon  the  current  acquisition  approach  characterized  by  “ffeeze-and-build”  and  instead  concentrate  on  a  new 
acquisition  philosophy  typified  by  evolution  and  the  ability  to  “leverage  and  adapt.”  To  effectively  meet  the  new  threats, 
emphasis  must  shift  to  evolving  functionality,  product  and  force  configuration 

DoD  must  also  ensure  that  current  laws  and  regulations  are  congruent  with  creating  a  Plug  &  Fight/Play  capability. 
Proper  legislative  and  regulatory  changes  must  be  proposed  to  enable  more  flexibility  in  reallocating  funds  between  the 
acquisition  phases,  and  to  provide  additional  funds  for  implementing  the  OS  Process  in  legacy  systems. 

To  effectively  implement  Plug  &  Fight/Play,  current  budget  processes  must  become  adaptable  to  needs  and  requirements 
of  the  OS  Process.  80%  of  the  respondents  to  an  OS-JTF  study  of  236  weapons  systems  programs,  representing  552 
PEOs,  PMs,  and  their  staff,  regard  budget  inflexibility  as  a  major  obstacles  to  OS  implementation.  A  funding  scheme 
more  receptive  to  OS  Processes  would  be  the  first  step  toward  removing  budget-related  obstacles.  The  demand  that  all 
elements  of  a  system  within  a  particular  appropriation  be  funded  the  same  way  works  against  aligning  buying  practices 
with  technology  cycles.  How  predictably  one  expends  the  program  funds  must  not  be  more  important  than  how 
effectively  those  funds  are  applied.  DoD  program  lifetimes  are  so  long  that  not  requiring  more  than  your  allotted  share 
of  the  funding  pool  is  far  more  important  than  what  value  is  delivered  for  the  funds  expended. 
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The  Most  Crippling  Impediments  (cont) 


•  NIH  (“Not  Invented  Here”) 

-  OS  Process  is  vital  for  parochial  Title  10  interest,  but  difficult  to  adapt 

-  OSD  sponsorship  invokes  suspicions,  vulnerabilities,  prerogatives 

-  With  OS  Process,  particularly  easy  to  invoke  usual  excuses: 

•  “We’re  already  doing  that” 

•  “We  don’t  need  to  do  that” 

•  “You  can’t  make  us  do  that  (Title  10)” 


•  Lack  of  intense  motivation  and  vigorous  commitment 

-  This  type  of  change  will  not  naturally  occur  —  requires  aggressive  leadership 

[ex:  AF  infusion  of  reliability  into  TACAIR] 

-  Commitment  at  some  lower  DoD  and  industry  levels  for  program  survival 

[ex:  JSF.  IEWCS] 

-  Senior  Leadership  not  there  yet 


OS  Process  can  be  done  and  would  have  massive  benefits, 
but  the  barriers  preclude  its  wide  implementation 
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Aggressive  leadership  presence  and  long-term  commitment  is  essential  for  effective  implementation  of  Plug  &  Fight/Play. 
Accountability  for  long-term  performance  is  completely  missing  in  within  DoD.  The  mentality  characterized  by  “we’re 
already  doing  that,”  “we  don’t  need  to  do  that,”  and  “you  can’t  make  us  do  that,”  resulting  from  misinterpretation  of  USC 
Title  10,  must  be  replaced  by  open-minded  attitudes  regarding  change  and  an  acquisition  culture  amenable  to  OS. 

In  order  to  fight  jointly,  the  Services  must  have  an  interoperable  system-of-systems  that  is  based  on  DoD  operational  and 
systems  architectures  that  are  integratable.  If  each  Service  uses  the  OS  Process,  but  each  defines  its  own  unique  process  for 
developing  its  operating  and  systems  architectures,  then  it  is  unlikely  that  those  architectures  will  be  integratable  across 
Services.  This  strongly  suggests  that  we  reevaluate  USC  Title  10  to  be  sure  that  there  are  no  obstacles  to  the  use  of  the  OS 
Process  to  interoperable  systems-of-systems. 

The  DoD  acquisition  culture  is  based  on  short-term  redistribution  of  tax  dollars  rather  than  long  term  planning  for  the 
delivery,  upgrade,  and  sustainment  of  military  capability.  Current  DoD  acquisition  planning  is  a  process  of  figuring  out 
how  to  cram  as  many  programs  as  possible  into  the  available  budget  without  breaking  any  of  them  so  badly  that  they  risk 
termination.  This  is  coping  rather  than  a  modernization  plan.  Once  a  program  has  made  it  through  the  new  start  process, 
all  of  the  capability  increase  and  sustainment  decisions  within  and  across  are  subordinated  to  these  fiscal  considerations. 
As  a  consequence,  programs  are  continually  over-specified  and  under-programmed,  leaving  them  to  drift  from  execution 
crisis  to  execution  crisis. 

Another  issue  related  to  the  current  DoD  acquisition  culture  is  that  it  is  a  “System”  culture.  Program  boundaries  are  drawn 
at  a  very  high  level,  and  the  acquisition  processes  employed  for  the  “System”  are  deemed  acceptable  at  every  level  within 
the  program.  This  guarantees  that  sub-systems  baselines  are  frozen  early  and  delivered  late  and  obsolete  —  with  virtually 
no  consideration  for  the  implications.  The  System  culture  has  also  blinded  DoD  to  the  extremely  high  leverage  that  buying 
below  the  systems  level  has  on  the  DoD  budget.  Since  there  are  more  tax  dollars  redistributed  below  the  major  system 
level  than  above,  and  since  these  dollars  are  the  under-pinning  for  jobs,  congressional  and  departmental  interest  and 
support  for  improvements  in  depot/arsenal/yard  operations  is  thin. 
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According  to  the  OS-JTF  survey,  mentioned  earlier,  barriers  to  OS  implementation  indeed  exist  and  resistance  to  the 
application  of  the  OS  process  is  expected.  A  large  majority  of  those  who  responded  to  the  survey  are  facing  technical 
barriers  in  implementing  OS.  Moreover,  half  of  the  respondents  feel  that  their  job  will  become  more  difficult  as  a  result 
of  applying  OS. 

Regarding  organizational  (i.e.,  structural  or  cultural)  barriers,  a  majority  of  the  respondents  to  the  OS-JTF  survey 
reported  facing  some  organizational  barriers  in  implementing  OS.  A  large  majority  of  the  respondents  regard  budget 
inflexibility,  absence  of  training,  lack  of  a  defined  OS  implementation  process,  DoD  culture  and  politics,  and 
bureaucracy  as  potential  obstacles  to  OS  implementation.  Additionally,  they  also  believe  that  absence  of  real  incentives, 
lack  of  awareness,  conflicting  policies  and  guidelines,  no  involvement  in  top  level  OS  decision  making,  and  opposition 
from  government  decision  makers  are  potential  obstacles  to  OS  implementation.  Interestingly,  only  about  one-third  of 
the  respondents  regarded  opposition  from  the  industry  to  be  an  obstacle. 
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Conclusions 

•  Open  Systems  Process  is  fundamental  to  many  DoDpriorities  that  are  dependent  upon  a 
process-based  approach 

-  JV  2010  and  Service  equivalents  -  Reduced  cycle  time  and  ownership  costs 

-  Force  modernization  -  Favorable  industrial  base  realignment 

Open  Systems  Process  is  a  Warfighting  and  Title  10  essential  core  value 

•  Forces,  systems,  and  processes  need  to  leverage  change: 

-  Configure  Forces,  systems  and  processes  for  continuous  viability 

-  Achieve  architecture-driven  modularity 

-  Manage  to  the  natural  cycle  rates  of  underlying  components 

•  Open  Systems  Process  is  based  upon  a  hierarchy  of  architectures  and  standards  developed 
with  a  performance-based  collaborative  approach 

•  Unlikely  that  DoD  can  implement  Open  Systems  Process  by  usual  bureaucratic  means 

-  Open  Systems  Process  is  a  cultural  and  budget  challenge-  process  is  within  our  grasp 

-  Requires  support  from  DoD,  Administration,  Hill,  and  Industry 

-  Need  to  reconfigure  Forces,  systems,  and  management  processes 

-  Removing  impediments  is  most  important 

JEtequiresjaggres^^ 
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The  OSTF  finds  it  unimaginable  that  a  number  of  DoD  priorities  can  be  achieved  without  a  massive  infusion  of  an  OS 
Process  and  related  investment  to  implement  OS  architectures. 

Example  priorities  include: 

•  JV  2010  and  the  Service  equivalents,  with  their  high  dependence  upon  rapid,  collaborative  responses  with  distant 
ad  hoc  forces  and  all  the  associated  planning,  deployment,  and  sustainment  tasks  --  all  dependent  upon  a  genuine 
Plug  &  Fight/Play  capability  across  the  Forces. 

•  Force  Modernization,  which  appears  largely  unaffordable  in  a  budget  which  is  already  severely  constrained  and,  in 
the  opinion  of  some,  may  worsen  dramatically.  The  economies,  expediencies,  and  ability  for  tech  refresh  of  OS 
will  be  essential  for  programs  to  be  sold  and  remain  viable. 

•  Reduced  Cycle  Time  and  Ownership  Cost,  being  driven  in  the  wrong  direction  by  recent  developments  such  as  a 
consolidating  industrial  base,  uneconomic  lot  buys,  dwindling  supplier  base,  and  program  redirections.  OS  is  a 
common  denominator  which  can  dramatically  improve  both  cycle  time  and  ownership  cost  by  leveraging  existing 
architectures  and  commercial  investment  and  market  volume. 

•  OS  and  the  OS  Process  is  not  just  an  OSD/JCS  joint  thing,  it  is  an  Essential  Core  Value  for  Service  Warfighting 
and  Title  10  responsibilities. 

Forces,  Systems,  management  processes,  and  oversight  mechanisms  are  too  oriented  toward  static  solutions  for  a  static 
world,  defying  the  realities  of  today’s  world.  Such  an  orientation  is  a  road  to  failure,  as  seen  all  around  us  in  force 
deployment  problems  and  programs  at  great  risk  for  being  no  longer  viable. 

DoD  Forces,  Systems,  management  processes  all  must  be  re-envisioned  and  reconfigured  as  crucibles  to  leverage 
change  so  as  to  remain  viable  throughout  the  entire  life  of  the  Forces  and  Systems. 


10/19/98  14:25 


DSB  OSTF  FINAL  REPORT 


page  75 


DSB  OSTF  FINAL  REPORT 


Continuous  evolution  can  be  economically  and  technically  achieved  only  through  extensive  use  of  smart, 
architecturally-driven  modularity,  whereby  Force  and  Systems  are  seen  as  a  structure  of  F3I  “sockets”  to  enable  the 
natural  cycle  rates  of  the  underlying  components. 

Finally,  DoD  management  and  oversight  processes  must  be  revamped  to  enable  the  needed  continuous  evolution  from 
requirements  generation  and  system  concept  development  through  field  logistics  support.  Current  processes  are 
hostile  to  the  needed  OS  measures. 

The  recommended  OS  Process  is  based  upon  a  hierarchy  of  architectures  and  their  associated  interface  standards.  A 
well  crafted  hierarchy  is  necessary  to  simultaneously  achieve  the  benefits  of  Plug  &  Fight,  Plug  &  Play,  and  the 
economies  of  commercial  components.  These  are  each  unique  attributes  with  their  own  sets  of  enabling  conditions. 
The  architectures  required  to  achieve  each  attribute  are  different  and  must  all  be  carefully  coordinated  or  they  will 
thwart  each  other. 

Each  architecture  and  the  associated  interface  standards  should  be  developed  and  maintained  with  a  performance- 
based  collaborative  approach  in  which  Line  Authority  establishes  the  end  objectives  and  the  stakeholders  determine 
the  “how.” 

Although  the  the  basics  of  OS  are  in  hand  and  readily  understood,  DoD  will  not  achieve  widespread  implementation 
by  its  natural  processes.  OS  Process  is  an  institutional  challenge.  DoD  must  revamp  a  number  of  processes, 
something  DoD  does  only  with  great  pain.  The  transformation  needs  to  include  oversight  processes  as  well  and  will 
require  support  from  throughout  DoD,  the  Administration,  and  the  Hill.  Industry  will  have  a  large  role  to  play  and  that 
support  should  be  requested. 

This  DoD  OSTF  and  the  OS-JTF  have  each  concluded  that  that  removing  the  impediments  to  OS  implementation  is  a 
critical  requirement.  Each  Task  Force  has  identified  a  number  of  impediments  and  these  should  be  explicitly  attacked. 

Finally,  we  need  to  reconfigure  Forces,  Systems,  and  key  processes  to  enable  continuous  evolution  for  life-long 
viability. 

These  are  radical  recommendations  for  DoD  and  successful  implementation  will  require  aggressive  leadership, 
championed  by  the  SecDef  and  Service  Secretaries. 
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Recommendations 

(1)  Establish  Special  Assistant  for  OS  Process 
Implementation 

(2)  Take  Immediate  Program  Actions 

-  Direct  preliminary  efforts 

-  Designate  pilot  programs 

(3)  Institutionalize  OS  Process 

-  Implement  and  mandate  Open  Architectures 

-  Revamp  management  processes 

(4)  Leadership  and  Championing 
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Recommendations 

-  Establish  Special  Assistant  for  OS  Process  Implementation  - 

Appoint  a  Special  Assistant  for  OS  Process  Implementation  within  immediate  office  of  the 

SecDef 

•  Focus  on  permeating  the  process,  not  individual  solutions 

•  Normal  DoD  mechanisms  inadequate  to  broadly  and  effectively  implement  an  OS  Process 
(ex.  existing  OSD  Executive,  Steering  Group,  Agency,  Lead  Service,  etc.) 

-  Precluded  by  inexperience  and  organizational  impediments,  equities,  prerogatives 

•  Effective  implementation  requires  empowered  advocate,  solid  OS  Process  experience 

-  Provocateur,  advocate,  guide,  expert  counsel,  mentor 

-  Map  general  implementation  path,  recommend  actions  and  direction 

-  Executive  advisor  to  SecDef,  CJCS,  and  staffs 

-  Implementation  secretariat,  staffed  by  OSD  Open  Systems  Joint  Task  Force 

•  Appointing  a  Special  Assistant  to  the  SecDef  is  markedly  superior  to  normal  mechanisms 

-  Ensures  someone  with  considerable  industry  and  DoDexperience 

-  Probably  no  single  individual  with  all  the  desired  experience  and  stature,  but  can  get  close 
enough  to  jumpstart  the  process 

-  Have  identified  a  sample  candidate  from  industry  poD  candidates  lack  sufficient  industry 
experience) 

•  Could  support  with  a  USD(A&T)/VCJCS/ASD(C3I)  OS  Implementation  Board 


The  OSTF  found  that  a  major  cultural  change  is  required  in  the  way  the  DoD  manages  and  oversees  systems  acquisitions. 
Because  the  former  culture  is  deeply  ingrained  in  die  workforce,  the  regulations,  and  the  normal  mode  of  business,  it  is 
believed  that  a  Special  Assistant  in  the  immediate  office  of  the  SecDef  is  required  to  implement  these  changes. 
Significant  rank  and  authority  are  needed  to  make  the  change  effective  and  permanent.  Current  management  structures 
within  the  DoD  are  too  wedded  to  the  old  way  of  doing  business. 

The  Special  Assistant  would  serve  as  the  advocate  for  the  OS  Process,  and  should  therefore  have  considerable  experience 
with  OS  Processes.  The  principal  roles  would  include  being  the  chief  advocate,  chief  OS  Process  advisor  to  the  senior 
leadership,  management  and  technical  expert,  guide,  counselor,  provocateur,  and  —  when  needed  —  a  point  of  disciplined 
strength. 

The  Special  Assistant  will  head  a  Secretariat  staffed  by  the  present  OS-JTF,  augmented  as  required.  The  Secretariat  will 
map  a  pathway  to  full  implementation  of  the  OS  Process,  recommend  policy  to  senior  leaders,  recommend  actions 
needed  to  ensure  compliance  with  OS  policies  to  SAE,  PEO  and  PM  officials,  and  issue  direction  as  appropriate. 

The  Special  Assistant  should  have  considerable  relevant  industry  experience.  The  OSTF  does  not  disparage  the  current 
DoD  acquisition  work  force,  but  believes  that  OS  is  sufficiently  new  to  DoD  that  there  are  few,  if  any,  candidates  who 
possess  the  minimum  range  and  depth  of  relevant  experience.  Industry,  on  the  other  hand,  has  been  engaged  in  OS  for 
several  decades,  so  a  suitable  candidate  with  knowledge  of  both  OS  and  DoD  acquisition  should  be  identifiable. 

As  an  existence  theorem  that  a  suitable  candidate  can  be  found,  the  OSTF  has  identified  such  a  person. 
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Recommendations 

-  Immediate  Programs  Actions  - 

There  are  some  specific  measures  which  can  and  should  be  taken  immediately 

•  JCS  within  nine  months  amend  ail  MNS  and  ORDs  to  require  OS  Process  attributes 

-  Continuing  viability 

-  Architecture-driven  modularity 

-  Configure  and  manage  to  leverage  natural  cycle  rates  of  components 

•  USD(A&T)  within  three  months  direct  all  programs  to 

-  Develop  a  Viability  Risk  Mitigation  Program  and  adapt  a  preliminary  formal  OS  Process 

-  Conduct  a  Viability  Risk  Analysis  and  develop  a  mitigation  strategy  —  compliance  or 
approved  Migration  Plan  within  1  year 

•  Immediately  implement  an  OS  Process  to  develop  architectures,  infuse  architecture-driven 
modularity,  and  capture  OS  attributes 

•  Fully  integrate  OS  Process  results  into  products,  management  processes,  acquisition  actions 

•  Make  OS  per  OS  Process  an  immediate  mandatory  Source  Selection  Criteria 

•  Mandatore  milestone  review  topic  at  all  levels,  fully  compliant  with  approved  migration  plan, 
within  earliest  of  either  two  years  or  two  milestone  reviews 

•  USD(A&T)  immediately  designate  pathfinding  OS  Process  major  programs  (ex:  NMD, 
TAMD,  JTRS,  etc.) 
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The  OSTF  does  not  want  to  preempt  options  of  the  proposed  Special  Assistant,  but  there  are  important  steps  which  can 
be  taken  immediately  to  start  the  OS  Process  in  current  programs.  Recommend  that: 

•  Chairman  JCS  within  six  months  augment  all  MNS  and  ORDs  to  require  the  OS  Process  attributes  of  continuing 
viability  of  forces  and  systems,  architecture  driven  modularity,  and  product  configurations  and  management 
processes  to  better  accommodate  the  natural  cycle  rates  of  underlying  components  and  imposed  constraints. 

•  USD(A&T)  within  three  months  direct  all  programs  to  develop  a  Viability  Risk  Mitigation  Program  based  upon  a 
viability  risk  analysis-driven  Mitigation  Strategy  and  Migration  Plan. 

•  Migration  Plans  will  be  submitted  for  approval  by  milestone  authorities  within  one  year. 

•  Programs  will  stand  up  a  preliminary  formal  OS  Process  to  implement  the  Migration  Plan.  OS  Process  and 
Migration  Plan  results  will  be  integrated  into  all  products,  management  processes,  and  acquisition  actions  — 
particularly  Source  Selection  Criteria  —  within  one  year. 

•  Compliance  with  this  directive  will  be  a  mandatory  milestone  review  topic,  with  full  compliance  with  the 
approved  Migration  Plan,  within  the  earliest  of  either  two  years  or  two  milestone  reviews 

•  USD(A&T)  designate  several  major  programs  with  extraordinary  need  for  OS  attributes  as  OS  Process 
Pathfinder  Programs.  Candidates  include  National  Missile  Defense,  Theater  Air  &  Missile  Defense,  and  Joint 
Tactical  Radio  System. 

•  These  initiatives  can  be  taken  in  the  near  term,  and  would  provide  a  significant  impetus  to  launching  the  OS 
Process  as  the  preferred  method  of  systems  acquisition. 
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Recommendations 

-  Institutionalize  OS  Process  - 

Mandate  &  fully  implement  needed  DoD-wide  interoperability  architectures 
( example  domains:  C4ISR,  weapons  systems,  M&S,  logistics  management  systems,  etc.) 

•  For  each  designated  interoperability  domain,  establish  an  Architecture  Control  Board  and 
supporting  structure  at  OSD/JCS  and  Service  levels,  and  throughout  subordinate  levels 

*  Suggest  an  approach  based  upon  classic  Program  Office  Configuration  Control  Board 

-  Advisory  to  Line  Authorities 

•  Establish  needed  functionality 

•  Establish  adequacy  of  proposed  architectures  and  compliance  with  higher-tier  architectures 

•  Evaluate  proposed  changes 

•  Assure  integrity  of  processes 

•  Establish  and  oversee  compliance  mechanisms 

-  OSD/JCS  Architecture  Control  Board  is  additional  role  of  existing  ACC 

-  Each  board  should  be  supported  by  genuine  architects/system  engineers  acting  in  the  interest 
of  the  Line  Authority  being  advised 


The  OSTF  can  not  imagine  that  DoD  can  meet  the  operational,  budget,  acquisition  and  management  challenges 
identified  in  this  report  without  a  broad  based  hierarchy  of  well  crafted  architectures  along  the  lines  it  has 
described.  Developing,  implementing,  and  maintaining  complex  architectures  in  a  difficult  and  demanding  world  is 
a  tough  problem  requiring  structure  and  discipline. 

Recommend  that  the  USD(A&T)  and  Chairman  JCS  establish  the  Architectural  Control  Board  (ACB)  as  the  formal 
process  for  administering  architectures  to  encourage  the  simultaneous  achievement  of  the  often  conflicting 
objectives  of  (1)  Plug  &  Fight,  (2)  Plug  &  Play,  and  (3)  capturing  the  benefits  of  COTS.  In  many  cases  the  ACB 
and  engineering  support  can  be  additional  roles  for  existing  bodies. 

The  OSTF  suggests  that  the  ACB  be  organized  similarly  to  the  Configuration  Control  Boards  found  in  System 
Program  Offices.  The  CCB  is  advisory  to  the  Line  Authority,  the  Program  Manager  (who  is  often  the  CCB 
Chairman).  The  power  of  the  CCB  is  that  the  Program  Manager  requires  that  all  relevant  actions  flow  through  the 
CCB  as  part  of  the  decision  staffing  process  --  subordinates  know  that  cooperation  and  compliance  are  essential  for 
milestone  decisions. 

ACB  topics  would  include  the  functionality  needed  from  subject  architectures,  adequacy  of  proposed  architectures, 
and  evaluating  proposed  architectures  and  related  standards.  It  is  preferred  that  the  process  of  developing 
architectures  and  selecting  standards  be  collaborative  amongst  the  stakeholders.  Experience  with  the  ATA  and  JTA 
argue  that  it  is  necessary  to  start  with  a  mandated  initial  architecture  and  to  amend  and  grant  waivers  as  necessary 
to  resolve  problems. 

Some  tiers,  such  as  for  Systems-of-Systems  and  the  Single  Integrated  Air  Picture,  may  maintain  an  internal 
architecture  and  ACB  for  management  purposes,  but  may  implement  needed  interface  controls  primarily  through 
other  mechanism  such  as  the  ACC  and  the  JTA. 

Architecting  and  System  Engineering  are  demanding  disciplines  requiring  a  high  level  of  expertise.  It  is  essential 
that  each  ACB  have  very  competent  engineering  support  acting  in  the  interest  of  the  Line  Authority. 
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Recommendations 

-  Institutionalize  OS  Process  (cont)  - 

•  OSD  and  JCS  immediately  enforce  existing  policies  or  change  them 

•  USD(A&T)  immediately  and  explicitly  attack  each  impediment  identified  by  this  OSTF 
and  the  OS-JTF  survey 

•  New  Special  Assistant  for  OS  Process  Implementation  within  six  months  roadmap  a 
structured  effort  to  (1)  revamp  relevant  management  and  oversight  processes,  (2)  establish 
incentives,  and  (3)  attacking  impediments 

-  Example  domains  for  revamping  :  requirements,  cost  and  budget,  program  management, 
support  processes,  source  selection,  performance  measures,  reporting  and  oversight 

-  Coordinate  closely  with  other  reform  efforts  such  as  Acquisition  Reform  &  RMA 

•  USD(A&T)  and  CJCS  direct  revamping  per  the  roadmap 

-  Include  with  other  special  reform  activities 

-  Develop  end  objectives  and  implementation  plans  within  4  months  of  go-ahead 

-  First  revision  of  all  directed  processes  within  1  year 

•  Immediately  grant  interim  relief  for  programs  to  start  tailoring  legacy  program 
management  processes  for  an  OS  Process 


10/19/98 14:23  «1 


There  are  already  policies  in  effect  requiring  elements  of  an  OS  Process  (e.g.  DoD  5000.2-R).  Unfortunately, 
compliance  and  understanding  is  spotty.  The  OSD  and  JCS  should  enforce  these  policies,  and  provide  training  to 
assist  the  workforce 

Serious  impediments  have  been  identified  by  this  OSTF  and  the  OSD  OS-JTF.  USD(A&T)  should  direct  immediate 
action  to  eliminate  or  minimize  these  at  all  levels  of  DoD. 

The  Special  Assistant  should  create  a  viable  roadmap  that  will  lead  DoD  to: 

•  Institutionalize  an  OS  Process  by  revising  the  existing  DoD  management  and  oversight  practices,  and  mandate 
an  OS  Process  for  all  new  acquisitions  and  legacy  system  and  subsystem  upgrades.  It  is  critical  to  establish 
effective  OS  architectures  in  new  acquisitions,  as  it  is  difficult  to  retrofit  to  an  OS  later. 

•  Establish  incentives  for  program  managers  and  contractors  to  aggressively  exploit  the  OS  Process  as  a  core 
value. 

•  Attack  and  eliminate  impediments  that  prevent  or  hamper  the  OS  Process.  The  OSTF  finds  the  institutional 
impediments  to  be  the  greatest  block  to  achieving  OS  attributes 

•  Task  Special  Assistant  to  direct  the  revamping  efforts  described  in  the  roadmap. .  The  roadmap,  including  end 
objectives  and  implementation  plans,  should  be  in  place  within  four  months  of  appointment,  initial  revisions 
being  in  place  within  one  year  with  Migration  Plans  for  full  implementation. 

•  PEOs  and  program  managers  could  implement  many  of  the  recommendations  now  if  given  the  latitude  to  do  so. 
USD(A&T)  should  grant  broad  enabling  interim  relief  pending  revamping  of  mandated  procedures. 
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Recommendations 

-  Institutionalize  OS  Process  (cont)  - 

•  Establish  Task  Force  to  examine  implications  for  industrial  base,  particularly  2nd 
and  3rd  tier  suppliers 

•  Establish  structured  process  for  early  proactive,  consistent,  and  constructive  DoD 
participation  in  relevant  industry  standards  bodies 

•  Revise  OS-JTF  role 

-  Continue  current  roles 

-  Become  Secretariat  to  SecDef  Special  Assistant  for  Implementation 

-  Nominate  more  senior  director  with  industry  credentials,  institutional  credibility, 
and  historical  perspective  on  the  challenges 

-  Augment  staff  skill  mix  to  include  warfighter,  program  manager,  engineer, 
logistician,  cost  analysis,  budget,  and  test  experience 

•  Establish  government/industry  OS  Process  Coordination  and  Advisory  Council 
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Infusion  of  OS  Processes  throughout  the  defense  industrial  base  is  essential,  and  will  change  the  face  of  defense 
contracting.  DoD  has  some  understanding  of  the  dynamics  at  the  prime  level;  far  less  so  at  the  second  and  third  tiers. 
A  Task  Force  should  be  established  to  examine  the  probable  impacts  on  industry  of  the  adoption  of  an  OS  Process. 

Successful  implementation  of  the  OS  Process  depends  on  industry  standards  that  are  formalized  through  various 
standards  bodies  (i.e.  ANSI,  IEEE,  SAE,  etc.)  Standards  bodies  tend  to  be  forward  thinking,  incremental  in  their 
approach,  and  deliberative  in  crafting  solutions  which  balance  the  many  competing  equities  in  ways  acceptable  to  all. 
DoD  has  already  reaped  enormous  benefits  from  embracing  commercial  standards.  Past  experience  has  demonstrated 
that  DoD  has  realized  even  greater  benefits  from  proactively  participating  in  the  standards  bodies  within  the  format  of 
the  bodies.  Industry  has  proven  receptive  when  DoD  has  participated  in  a  coordinated  manner,  making  thoughtful 
contributions,  expressing  their  requirements  sufficiently  early  in  the  process,  and  remaining  flexible  and  constructive 
throughout  the  sometimes  interminable  consensus-building  proceedings. 

Unfortunately,  DoD  often  participates  in  a  catch  up  mode.  Although  there  have  been  years  of  technology 
demonstration  projects  and  concept  development,  a  program  doesn’t  become  “real”  until  there  is  pending  EMD. 
Somewhere  in  the  transition  to  EMD  there  is  a  rush  to  try  to  catch  up  in  the  standards  area.  This  approach  is  poorly 
suited  to  industrial  consensus  processes  and  outcomes  are  often  predictably  disappointing. 

Recommend  that  USD(A&T)  establish  a  recognized,  disciplined,  funded  and  well  organized  process  for  participating 
in  these  bodies  at  all  levels  necessary  to  ensure  that  its  interests  are  met 

To  be  effective,  the  Special  Assistant  for  Implementation  needs  to  be  backed  up  by  a  well-experienced  staff. 
Recommend  that  the  mission  of  the  OSD  OS-JTF  be  expanded  to  serve  as  the  Secretariat  for  OS  Process 
implementation. 

An  effective  OS  Process  will  be  complex  and  far  reaching  across  DoD  and  the  industrial  base.  Far  grater 
communication  and  cooperation  is  needed.  Recommend  that  an  Advisory  Council  be  established  to  provide  both 
government  and  industry  voice,  provide  advice  to  the  Special  Assistant,  and  encourage  coordination  of  efforts  in  a 
neutral  venue  among  contractors  who  are  otherwise  competitors. 
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Recommendations 

-  Leadership  and  Championing  - 

•  DoD  Warfighting  and  Title  10  capabilities  on  downward  spiral 

•  An  Open  Systems  Process  is  requisite  to  many  DoD  priorities 

•  Open  Systems  Process  is  no  panacea,  but  is  a  cornerstone  for  all  solutions,  a  historic  endowment 

•  Implementing  OS  Process  is  an  institutional  issue  -  methodology,  technology  are  manageable 

•  Time  is  of  the  essence  due  to  need  and  change  of  administration. 

•  Such  change  comes  only  with  aggressive  leadership  [ex:  AF  TACAIR] 

Basically  a  binary  choice 

•  Energetic  and  dynamic SecDef,  JCS,  and  Service  leadership  could  be  decisive 

-  With  it,  there  is  a  chance;  without  it,  broad  implementation  will  not  happen 

•  Would  require  working  with  Mr.  Cohen  and  Mr.  Hamre  to  develop  a  strong  personal  commitment 

•  Equal  commitment  needed  from  remaining  leadership 


Task  Force  recommendations  assume  aggressive  implementation. 

If  DoD  leadership  cannot  commit,  then  merely  issuing  guidance,  including  OS  Process  | 
in  ongoing  reforms,  and  helping  the  system  do  as  best  it  can  will  not  be  sufficient  | 

10/19/91  14:15  13 


Capabilities  laid  out  in  JV2010  and  Service  equivalents  are  essential  to  the  continued  viability  of  U.S.  forces. 
Unfortunately,  current  DoD  warfighting  and  Title  10  capabilities  are  already  in  decline  as  a  result  of  the  significantly 
shifted  world  situation  and  steep  declines  in  the  budgets.  DoD  cannot  meet  these  challenges  without  fundamental 
change.  While  there  are  neither  “silver  bullets”  nor  panaceas  for  all  problems,  the  OSTF  argues  that  the  OS  Process  is  a 
cornerstone  of  the  solutions  that  will  be  needed  to  meet  our  current  and  future  challenges. 

The  OSTF  finds  that  OS  technology  and  methodology  is  within  the  grasp  of  DoD:  the  challenge  that  DoD  faces  is 
institutional.  The  old  ways  are  ingrained  and  resources  are  scarce.  The  needed  change  will  require  proactive,  aggressive 
leadership.  The  OSTF  is  concerned  that  there  is  sufficient  time  to  implement  the  necessary  initiative  given  the  pending 
turnover  of  the  administration. 

Change,  and  especially  significant  institutional  change  of  the  magnitude  of  the  OS  Process,  is  impossible  without  strong 
leadership  commitment  at  the  highest,  as  well  as  subordinate,  levels.  While  the  “top  management  commitment”  mantra 
has  been  overused  to  the  point  of  being  a  cliche,  it  nonetheless  describes  a  fundamental  reality:  if  top  management  is  not 
deeply  committed  and  personally  involved  on  a  sustained  basis,  then  change  will  not  occur.  The  OSTF  recommends  that 
SecDef  Cohen  communicate  a  strong  personal  determination  that  the  OS  Process  become  the  standard  way  of  doing 
business  within  DoD,  and  that  he  secure  the  firm  and  determined  leadership  of  the  other  principal  executives  within  DoD 
and  the  Services. 

The  prognosis  for  OS  Process  implementation  is  binary,  and  dependent  upon  proactive  leadership  commitment. 
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Recommendations 

-  Leadership  and  Championing  - 

•  SecDef  within  45  days: 

-  Hold  off-site  with  Chairman,  Service  Secretaries,  Chiefs,  CAEs 

•  Secure  personal  commitments  to  Plug  &  Fight  and  OS  Process 

•  Press  Conference 

-  Shared  commitment  and  Call  for  Action 

-  Announce  action  leadership 

-  Formally  request  Dongressional,  Administration,  and  industry  support 

-  DoD-wide  call  for  identification  of  impediments  to  implementation 

•  Chairman,  Service  Secretaries,  Chiefs,  CAEs,  Agency  Heads  within  next  30 
days: 

-  Take  corresponding  actions 


Because  it  is  necessary  to  rapidly  implement  the  OS  Process  in  DoD,  several  activities  are  recommended  for  the 
near  term  (45  days). 

The  OSTF  recommends  that  the  SecDef  hold  an  offsite  with  Chairman  JCS,  JCS  members,  Service  Secretaries,  and 
Component  Acquisition  Executives  to  map  out  the  plan  for  the  change  to  OS  Process.  The  off-site  should  stress  the 
necessity  of  adopting  the  Plug  &  Fight/Play  and  OS  Process  concepts  for  DoD  systems.  The  results  of  the  off-site 
should  be  announced  with  significant  public  exposure  at  a  press  conference.  The  message  of  the  off-site  and  press 
conference  should  be  a  significant  shared  commitment  and  a  call  for  action  by  all  interested  parties  --  it  should 
announce  that  the  top  DoD  leadership  is  firmly  committed  to  the  OS  Process. 

The  SecDef  should  call  for  identification  of  all  impediments  to  the  OS  Process,  including  inputs  from  government, 
the  Services,  Congress,  and  industry  ...  all  interested  stakeholders.  Once  the  impediments  are  identified,  they 
should  be  removed  by  the  most  efficient  process  possible.  If  an  impediment  is  either  due  to,  or  a  consequence  of, 
legislation,  then  Congress  should  be  approached  to  change  the  law. 

It  will  be  necessary  to  gain  support  of  all  stakeholders  for  DoD  to  successfully  implement  OS  Process.  Without 
soliciting  the  opinions  of  Congress,  Administration,  government,  the  Services,  and  industry,  the  chances  of  success 
are  significantly  diminished. 
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ACQUISITION  AND 
TECHNOLOGY 


THE  UNDER  SECRETARY  OF  DEFENSE 

3000  DEFENSE  PENTAGON 
WASHINGTON,  DC  20301-3000 


14  July  1997 


MEMORANDUM  FOR  THE  CHAIRMAN,  DEFENSE  SCIENCE  BOARD 

SUBJECT:  Terms  of  Reference  -  Defense  Science  Board  Study  Task  Force  on  Open 

Systems 


I  request  that  you  establish  a  Defense  Science  Board  Task  Force  to  examine  the  benefits 
of,  criteria  for,  and  obstacles  to  the  application  of  an  open  systems  approach  to  weapon  systems, 
and  to  make  recommendations  on  revisions  to  DoD  policy,  practice,  or  investment  strategies  that 
are  required  to  obtain  maximum  benefit  from  adopting  open  systems.  The  Task  Force  should 
examine  application  to  new  defense  programs,  to  those  that  have  already  made  substantial 
investments  in  a  design,  and  to  those  that  are  already  fielded,  across  the  spectrum  of  weapon 
systems,  not  just  those  heavily  dependent  on  advanced  computers  and  electronics. 

Within  today’s  national  security  environment  and  budget  constraints,  the  Department  of 
Defense  has  chosen  a  strategy  of  relying  heavily  on  the  private  sector  for  achieving  needed 
operational  performance  and  cost  of  ownership  for  its  weapons  systems.  An  “open  systems 
approach”  appears  to  be  an  effective  way  to  field  superior  combat  capability  quicker  and  at  a 
more  affordable  cost.  Open  systems  may  achieve  improved  performance  and  lower  costs  by 
taking  advantage  of  competition  and  innovation  in  the  global,  commercial  marketplace.  In 
addition,  open  systems  could  serve  to  insure  that  the  US  military  has  access  to  cutting  edge 
technologies  and  products,  and  prevent  the  Department  from  being  locked  into  proprietary 
technology.  On  the  other  hand,  there  will  be  increased  up-front  costs  for  open  systems  that  must 
be  traded  against  the  downstream  benefits. 

The  Task  Force  should  address  the  following  questions: 

•  What  criteria  should  be  used  to  identify  specific  programs  that  would  benefit  most  from  an 
open  systems  approach? 

•  How  can  programs  that  are  already  committed  to  a  design  (whether  in  development, 
production  or  retrofit)  obtain  the  benefits  of  an  open  systems  approach?'  As  an  example, 
examine  the  potential  for  increased  application  of  open  systems  for  the  F-22  program. 

•  What  are  the  implications  of  open  systems  for  international  cooperative  programs?  How 
should  the  Department  quantify  the  life  cycle  costs  associated  with  an  open  systems 
approach?  What  other  metrics  should  be  used  forjudging  the  value  of  open  systems  (e.g., 
reduction  of  cycle  time,  fielding  of  new  technology  quicker)? 

•  What  tools  (e.g.,  COEA  tools,  wargaming,  costing,  risk  assessment,  related  models  or 
simulations)  must  be  developed  to  facilitate  the  use  of  an  open  systems  approach? 


•  What  are  the  principal  barriers  to  adopting  open  systems?  How  can  the  Department  achieve 
broader  acceptance  of  an  open  systems  approach  for  weapon  systems? 

•  What  level  of  industry  support  is  needed  for  adopting  an  open  systems  approach  and  how 
can  the  Department  encourage  such  support  ?  How  should  the  Department  select  which 
standards  and  architectures  to  use? 

•  What  are  the  risks  and  other  disadvantages  associated  with  adopting  an  open  systems 
approach,  and  how  can  the  Department  mitigate  those  risks?  How  are  weapon  systems 
different  from  commercial  systems?  What  requirements  cannot  be  met  through  use  of 
Commercial  Items? 

•  What  changes  are  needed  in  policy,  practice,  or  investment  strategies  to  implement  an 
effective  open  systems  approach?  What  investments  are  needed  in  the  near-term?  What 
means  of  enforcement  are  needed? 

The  Director,  Strategic  and  Tactical  Systems  will  sponsor  the  Task  Force.  Mr.  Peter 
Marino  and  Dr.  Wayne  O’Hern  will  serve  as  the  Task  Force  Co-Chairmen.  Mr.  H.  Leonard  Burke 
will  serve  as  the  Executive  Secretary,  and  Maj.  Wynne  Waldron  will  serve  as  the  Defense 
Science  Board  Secretariat  Representative.  The  Task  Force  should  begin  its  work  as  soon  as 
possible  and  provide  a  final  report  within  twelve  months. 

The  Task  Force  will  be  operated  in  accordance  with  the  provisions  of  P.L.  92-463,  the 
“Federal  Advisory  Committee  Act,”  and  DoD  Directive  5104.5,  the  “DoD  Federal  Advisory 
Committee  Management  Program.”  It  is  not  anticipated  that  this  Task  Force  will  need  to  go  into 
any  “particular  matters”  within  the  meaning  of  Section  208  of  Title  1 8,  U.S.  Code,  nor  will  it  cause 
any  member  to  be  placed  in  the  position  of  acting  as  a  procurement  official. 


//signed// 

R.  Noel  Longuemare 

Acting  Under  Secretary  of  Defense 

(acquisition  and  Technology) 


DSB  TASK  FORCE  ON  OPEN  SYSTEMS 
APPENDIX  C 


LIST  OF  PRESENTATIONS 


The  following  table  lists  presentations  briefed  to  the  DSB  Task  Force  on  Open  Systems: 


-  . .  Presenter 

Organization 

Hi  KtMBKEKM 

Sept.  16,  1997 

Mr.  David  Ream 

Director,  Standards  of  Conduct 
Office 

Standards  of  Conduct 

Sept.  16,  1997 

RADM  John  Gauss 

N60 

Open  Systems:  An  Operational  Perspective 

Sept.  16,  1997 

Dr.  Michael  Frankel 

SRI  International 

Army  Science  Advisory  Board  :  Technical 
Information  Architecture 

Sept.  16, 1997 

Mr.  Reginald  Varga 

Director,  Open  Systems  Avionics, 
Boeing  -  Phantom  Works 

Open  Systems  Architecture  and  the  aircraft 
defense  industry 

Sept.  16,  1997 

Mr.  William  Kiczuk 

Raytheon  TI  Systems 

Enabling  Open  Systems  Architectures 

Sept.  16,  1997 

Dr.  Patrick  Winston 

MIT 

NRAC  Committee  Report  on  Open 
Systems:  CVX  Flexibility 

Sept.  17, 1997 

Mr.  Jack  Bloodworth 

Boeing  Company 

Open  Systems  Architecture 

Sept.  17, 1997 

Mr.  Tofie  Owen,  Jr. 

SAIC 

Supportability  Perspective  on  Open 
Systems 

Sept.  17,  1997 

Dr.  David  Sundstrom 

Lockheed  Martin  Tactical 

Aircraft  Systems 

Open  Systems  :  A  Lockheed  Martin 
Perspective 

Sept.  17,  1997 

Mr.  Leonard  Burke 

OUSD(A&T)  OS-JTF 

Open  Systems  Implementation  Progress 

Oct.  9,  1997 

Mr.  Richard  McNarmara 

NAVSEA/PMS  450 

New  Attack  Submarine  Combat  System: 
COTS  and  Open  Systems  Initiatives 

Oct.  9,  1997 

Mr.  Tom  Graves 

ASC/AZ 

Performance  Based  Business  Environment 

Nov.  18,  1997 

Dr.  George  Heilmeier 

Chairman  Emeritus,  Bellcore 

Meeting  the  Open  Systems  Challenge 

Nov.  18,  1997 

VADM  Jerry  Tuttle  (Ret.) 

Oracle 

Navy  Perspective  on  Open  Systems 

Nov.  18,  1997 

Col  Chuck  Adams  (Ret.) 

Coopers  &  Lybrand 

Acquisition  Reform  Implementation, 
Industry  Survey 

Nov.  18,  1997 

Col.  Diana  .L.  Beardsley 

Director,  Avionics  Management 
Directorate,  WRAFB 

Common  Avionics 

Dec.  17,  1997 

Mr.  Dave  Kier 

Deputy  Director  National 
Reconnaissance  Office  (NRO) 

System  of  Systems 

Dec.  17,  1997 

Dr.  Frank  Perry 

DISA/D6 

Common  Operating  Environment 

Dec.  17,  1997 

COL  Garrettson 

DISC4 

Army  Open  Systems  Architecture 

Dec.  17,  1997 

Mr.  Dale  Adams 

AMC 

Modernization  through  Spares 

Jan.  27,  1998 

Mr.  A1  Newman 

MITRE  Corporation 

Joint  Tactical  Radio  System  (JTRS) 

Jan.  27,  1998 

Mr.  John  Osterholz 

Deputy  Director,  CISA 

Joint  Technical  Architecture 

Jan.  27,  1998 

Ms.  Tricia  Obemdorf 

Carnegie  Mellon  University/SEI 

Software  Engineering  Institute 

Feb.  23,  1998 

BG  “Mitch”  Mitchell 

NRO  -Director  of 

Communication 

Classified  Briefing 

Feb.  23,  1998 

Mr.  Chris  Wain 

TASC 

Task  Force  Assessment  on  JTRS 

Feb.  24,  1998 

Mr.  Alvin  Burgemeister 

Boeing  Commercial  Airplanes 

Air  Transport  Open  Systems:  A  Mixed 
Success 

Mar.  17,  1998 

Mr.  Fred  Ziska 

Rockwell  Collins 

Advantages  of  Supplier  Configuration 
Management  Control  and  Open  Systems 
Implantation 

Mar.  17, 1998 

Mr.  Leonard  Burke 

OUSD(A&T)  OS-JTF 

Status  of  Work  on  Final  Report 

Apr.  6,  1998 

Mr.  Peter  J.  Hancke,  et  al 

Lockheed  Martin 

NSSN,  Using  COTS  in  Military  Systems 

Apr.  7,  1998 

Messrs.  T.  Burbage,  M. 
Broadwell,  D.  Mayotte,  F. 
Spring,  G.  Hogarth 

Lockheed  Martin 

F-22  Program  Overview 

Apr.  7,  1998 

Mr.  Jon  Ogg 

F22  SPO 

F-22  Integrated  Avionics  Architecture 

Apr.  7,  1998 

Mr.  Ken  Fehr,  et  al 

ASC/YFFA 

F-22  Avionics  Lessons  Learned 
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JUSTIFYING  OPEN  SYSTEMS: 
WHY  DO  WE  CARE? 

by  GEN  Bruce  Brown,  USAF  (Ret) 


“The  nature  of  modem  warfare  demands  that  we  fight  as  a  joint  team.  This  was 
important  yesterday,  it  is  essential  today,  and  it  will  be  even  more  imperative 
tomorrow.  Joint  Vision  2010  provides  an  operationally  based  template  for  the 
evolution  of  the  Armed  Forces  for  a  challenging  and  uncertain  future.  ” 

John  M.  Shalikashvili 

Chairman  of  the  Joint  Chiefs  of  Staff 

It  is  the  view  of  the  DSB  Task  Force  on  Open  Systems  (OSTF)  that  Joint  Vision  2010  represents  a  sound  and 
thoughtful  roadmap  to  the  future  for  the  DoD  as  it  works  its  way  through  the  thicket  of  uncertainties  and 
alternative  futures  that  face  it  in  the  aftermath  of  the  Cold  War.  While  accommodating  change  is  always 
difficult,  the  new  and  uncertain  world  which  results  from  the  fall  of  the  Soviet  Union  presents  the  Department 
with  one  of  the  most  significant  discontinuities  with  which  it  has  ever  been  faced.  The  fallacy  of  attempting  to 
plan  precisely  in  such  an  environment  is  well  understood;  the  danger  of  being  precisely  wrong  is 
unacceptably  high. 

A  vision  describes  a  desired  end  state.  The  end  state  that  Joint  Vision  2010  describes  is  composed  of  the 
aggregate  capabilities  that  our  forces  must  posses  to  ensure  U.S.  military  superiority,  leadership,  and  the 
security  and  prosperity  of  the  American  people  in  the  twenty-first  century.  The  opening  paragraph  of  Joint 
Vision  2010  states: 

“Joint  Vision  2010  is  the  conceptual  template  for  how  America’s  Armed  Forces  will  channel 
the  vitality  and  innovation  of  our  people  and  leverage  technological  opportunities  to  achieve 
new  levels  of  effectiveness  in  warfighting.  Focused  on  achieving  dominance  across  the  range 
of  military  operations  through  the  application  of  new  operational  concepts,  this  template 
provides  a  common  direction  for  our  Services  in  developing  their  unique  capabilities  within  a 
joint  framework  of  doctrine  and  programs  as  they  prepare  to  meet  an  uncertain  and 
challenging  future.” 

More  specifically.  Joint  Vision  2010  describes  an  end  state  set  of  capabilities  which  are  radically  different 
from  those  our  forces  possess  today: 


“Enhanced  command  and  control,  and  much  improved  intelligence, 
along  with  other  applications  of  new  technology,  will  transform  the 
traditional  functions  of  maneuver,  strike,  protection  and  logistics. 

These  transformations  will  be  so  powerful  that  they  become,  in 
effect,  new  operational  concepts.” 
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Consistent  with  the  template  laid  down  by  Joint  Vision  2010,  each  of  the  Services  has  published  a  vision  of 
its  own  which  is  focused  on  its  unique  capabilities.  The  Army  has  published  Army  Vision  2010,  the  Navy 
Forward  From  the  Sea,  the  Marines  Operational  Maneuver  From  the  Sea,  and  the  Air  Force  Global 
Engagement. 

In  addition,  the  Joint  Staff  has  published  Concept  for  Future  Joint  Operations,  which 

“expands  Joint  Vision  2010’s  new  operational  concepts  to  provide  a  more  detailed  foundation 
for  follow-on  capabilities  assessments. . .  As  the  implementation  of  Joint  Vision  2010  unfolds 
and  our  concepts  of  joint  warfighting  evolve,  the  essential  task  is  to  gain  the  complete 
commitment  of  the  Services,  the  combatant  commands,  and  civilian  and  government  agencies 
to  achieving  the  key  characteristic  we  seek  for  our  Armed  Forces — the  ability  to  conduct 
dominant  operations  across  the  full  range  of  possible  missions — Full  Spectrum  Dominance. 

We  have  made  great  strides  in  developing  our  joint  warfighting  capabilities  in  the  last  ten 
years.  But  the  challenges  of  the  21st  century  demand  a  new  legacy  of  commitment  to  joint 
warfighting .” 

Descriptions  of  the  uncertain  future  world  our  forces  face  and  the  changes  that  they  must  make  to  prepare  for 
it  are  not  limited  to  the  Joint  Staff  and  the  Services.  For  instance: 

•  A  prevailing  theme  throughout  the  Quadrennial  Defense  Review  is  the  necessity  to  transform  today’s 
forces  into  a  much  more  joint  force  required  for  the  future. 

•  The  Defense  Reform  Initiative  characterizes  itself  as  the  third  element  of  a  DOD  corporate  vision  to 
transform  defense  strategy,  the  military,  and  the  business  practices  of  the  Department  in  order  to  prepare 
for  the  2 1st  century. 

•  The  National  Defense  Panel  report  is  titled  Transforming  Defense;  National  Security  in  the  21st  Century. 
The  report  is  entirely  concerned  with  describing  the  numerous  and  profound  changes  that  will  be  needed 
to  ensure  U.S.  national  security  in  the  21s*  century. 

•  In  remarks  to  the  Center  for  Strategic  and  International  Studies  on  May  22, 1997,  Secretary  Cohen  said: 

“In  March,  I  went  out  to  Ft.  Irwin  to  see  the  US  Army’s  Force  XXI  experiments  in  which  the 
Army’s  Experimental  Force  is  harnessing  the  power  of  digital  technology  and  using  the 
capability  it  provides  to  test  out  new  operational  concepts,  doctrine,  tactics,  and 
organizational  designs.  It  was  an  awe  inspiring  demonstration.  Few  who  see  it  in  action  can 
doubt  that  Force  XXI  will  revolutionize  land  warfare  by  linking  commanders,  planners  and 
shooters  with  digital  information  and  communications  technology,  cutting  through  the  fog  of 
war.  Force  XXI  is  the  much-vaunted  ‘Revolution  in  Military  Affairs’  made  real...” 

There  is  a  strong  and  constant  theme  throughout  these  documents  that  the  defense  budget  is  not  going  to 
increase  and  that  the  demand  for  forces  is  not  going  to  diminish  significantly.  It  is  clear  that  the  Department 
has  expended  and  is  expending  significant  resources  in  the  process  of  thinking  about  the  future  and 
attempting  to  understand  what  qualities  and  attributes  our  forces  must  possess  to  maintain  military  superiority 
in  the  21st  century. 
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It  is  also  clear  that  there  is  one  fundamental  attribute  which  is  critical  to  the  success  of  future  U.S.  forces  and 
which  underpins  all  concepts  of  future  force  effectiveness.  This  fundamental  attribute  is  JOINTNESS.  Our 
forces  are  going  to  have  to  reflect  a  degree  of  jointness  unprecedented  in  the  history  of  U.S.  armed 
forces.  In  a  word,  the  key  to  the  success  of  U.S.  forces  in  the  new  and  uncertain  world  facing  them  is  : 

JOINTNESS! 

JOINTNESS! 

JOINTNESS! 


HOW  IS  JOINTNESS  ACHIEVED? 

The  Task  Force  has  attempted  to  identify  alternative  paths  to  achieve  the  levels  ofjointness  which  have  been 
described  by  the  leadership  of  the  Department  as  critical  to  the  success  of  future  U.S.  military  operations.  To 
achieve  these  levels  of  jointness,  however,  will  require  much  more  than  a  technical  solution.  Achieving  “a 
degree  ofjointness  unprecedented  in  the  history  of  U.S.  armed  forces”  will  also  demand  major  institutional 
and  organizational  changes,  including  major  changes  in  many  familiar  Department  processes.  Many  of  these 
processes,  such  as  establishing  requirements,  force  readiness,  training,  developing  and  validating  doctrine, 
and  many  more,  have  today  a  heavy  Service  focus  which  will  have  to  be  broadened  to  produce  a  much  more 
intense  joint  perspective.  That,  in  and  of  itself,  will  be  a  difficult  task,  which  the  Task  Force  will  leave  to 
others  such  as  the  U.S.  Atlantic  Command  (ACOM)  which  was  established  to  help  facilitate  the  joint 
integration  and  training  of  our  forces..  The  Task  Force  will  confine  itself  to  recommending  those  technical 
changes  which  it  feels  will  be  required  to  provide  the  means  to  implement  the  necessary  institutional  and 
organizational  changes  throughout  the  Department. 

WHAT  DOES  JOINTNESS  MEAN? 

In  that  context,  therefore,  and  from  the  perspective  of  recommending  a  technical  solution,  what  does 
“jointness”  mean?  Purely  and  simply,  it  translates  into  “interoperability”.  There  is  a  strong  consensus  within 
the  Task  Force  that  the  operating  concepts  identified  in  Joint  Vision  2010  and  in  Service  and  other  joint 
vision  statements  have  little  chance  of  being  successfully  implemented  unless  there  is  a  major  increase  in  the 
level  of  interoperability  displayed  by  defense  systems  in  joint  operations  in  the  future. 

Rapid  deployment  of  highly  lethal  forces  over  long  distances  on  very  short  notice  is  both  an  implicit  and 
explicit  requirement  of  the  several  current  vision  statements.  This  means  that  the  U.S.  must  be  able  to  custom 
build  mission-specific  forces  from  widely  scattered  and  functionally  disparate  “piece  parts”  on  the  fly  and  do 
it  right  the  first  time.  It  means  we  can  no  longer  afford  the  luxury  (not  that  we  ever  could)  of  redundant  force 
elements  which  characteristically  result  from  Service-unique,  stovepipe  solutions,  including  the  heavy, 
ponderous  concomitant  Service-unique  support  tails  required.  Instead,  each  Service  must  be  able  to  provide 
what  it  does  best  in  the  form  of  light,  agile  force  elements  capable  of  being  quickly  and  smoothly  integrated 
into  a  coherent  and  lethal  whole. 

The  force  of  the  future  must  be  redesigned  to  meet  the  needs  of  a  volatile  and  ever  changing  world.  It  must  be 
composed  of  mutually  supportive  forces  able  to  react  to  a  short  or  no-notice  crisis.  Uncertainty  and  a  growing 
complexity  make  it  difficult  to  prepare  for  or  even  predict  the  types  of  contingencies  our  forces  may  have  to 
face.  Future  force  projection  may  be  executed  by  a  joint  force  or  even  a  multi-national  force.  Modem 
operations  will  almost  certainly  be  unified  in  nature,  joint,  interagency  and  multinational. 
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One  of  the  problems  with  a  no-notice  crisis  and  deployment  is  that  the  right  combination  of  forces  is  not 
always  available  or  even  in  close  proximity  to  the  area  of  conflict.  The  responding  CESfC  needs  to  be  able  to 
use  the  forces  at  hand  (close  to  the  area  of  conflict)  when  asked  to  respond  to  these  “come  as  you  are  crises”. 
In  the  future  he  will  not  have  the  luxury  of  building  up  his  forces  from  far  flung  staging  areas.  He  will  have  to 
“plug  and  fight”  with  the  forces  at  hand.  These  forces  will  have  to  arrive  in-theater  ready  to  fight. 

The  ability  to  integrate  large,  diverse  force  elements  into  a  complex  but  manageable  and  combat  effective 
whole  has  long  been  a  military  discriminator,  and,  in  modem  times,  no  major  power  has  been  as  good  at  it  as 
the  U.S.  But  the  doing  of  that  generally  has  taken  a  long  period  of  time,  both  from  the  standpoint  of  deploying 
the  forces  and,  once  deployed,  organizing  and  preparing  for  combat.  Recent  Defense  Science  Board  Task 
Forces  have  concluded  that  future  rogue  states  are  likely  to  have  learned  that  lesson  well  and  will  therefore 
move  quickly  in  any  future  aggression  so  as  to  deprive  the  U.S.  of  time  we  have  historically  needed  to 
respond.  These  DSB  Task  Forces,  accordingly,  have  recommended  solutions  involving  small,  distributed 
forces  that  will  require  levels  of  interoperability  and  information  technology  which  is  truly  “unprecedented  in 
the  history  of  U.S.  armed  forces”. 

INTEROPERABILITY  ACROSS  THE  ENTERPRISE 

It  will  profit  us  little,  however,  if  we  are  able  to  solve  the  difficult  problem  of  interoperability  only  for  the 
combat  forces.  Light,  agile,  and  lethal  combat  forces  will  have  little  military  utility  if  the  elements  of  the 
enterprise  upon  which  these  forces  depend  remain  large,  ponderous,  Service-unique,  and  heavy. 

Our  forces  will  primarily  be  CONUS  based  and  will  depend  on  a  combination  of  airlift  and  sealift  for  their 
rapid  mobility.  In  all  likelihood,  these  limited  airlift  and  sealift  resources  will  be  sufficient  to  move  only  the 
combat  forces  themselves;  it  is  unlikely  that  these  lift  forces  will  be  able  to  transport  the  typical  combat 
support  and  combat  service  support  forces  of  today  over  the  distances  and  within  the  timelines  we  now 
consider  likely.  The  combat  forces,  therefore,  that  will  make  up  these  future  joint  task  forces  must  be  able  to 
provide  needed  tactical,  and  logistical,  personnel  and  medical  support  to  each  other  across  the  enterprise. 
These  forces  will  have  to  arrive  in-theater  ready  to  fight  as  members  of  the  CINC’s  joint  forces.  These 
operations  will  require  interoperability  between  the  forces  of  our  different  services  and  between  forces  of 
different  nations  not  only  with  respect  to  combat  operations,  but  with  respect  to  logistic,  personnel,  and 
medical  support  as  well. 

For  the  purpose  of  this  report,  “logistics”  means  the  entire  spectrum  of  support  at  all  echelons  of  command. 
Future  logistic,  personnel,  and  medical  support  systems  must  provide  interoperable,  comprehensive,  and 
responsive  support  to  the  Joint  or  Combined  Force  Commander.  The  joint  logistic,  personnel,  and  medical 
support  forces  of  the  future  will  have  to  be  able  to  do  such  things  as: 

•  Replace  common  equipment  components  throughout  the  joint  or  combined  task  force 

•  Provide  equipment  maintenance  to  a  different  service  component  unit 

•  Exchange  parts,  fuel,  and  ammunition 

•  Electronically  exchange  logistic  support  data  and  information  rapidly  and  accurately  in  order  to  support 
our  just  in  time  delivery  of  critical  combat  equipment  and  supplies 
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•  Electronically  exchange  personnel  data  and  information  on  casualties  and  personnel  loses  in  order  to 
effect  replacement  personnel,  casualty  notification,  prompt  payment  of  death  gratuities,  etc. 

•  Electronically  exchange  the  medical  status  of  our  forces  as  they  wear  the  personnel  body  suits  of  the 
future 

•  etc. 

Interoperability  across  the  enterprise,  then,  extends  to  at  least  the  following  four  general  categories: 

•  How  we  create  the  force  (how  it  is  recruited,  trained,  organized  and  equipped.  It  ensures  we  prepare  to 
fight  in  a  joint  manner) 

•  How  we  generate  the  force  (projecting  the  force  and  mixing  the  forces.  It  requires  us  to  work  joint 
procedures,  policies,  and  plans  to  ensure  success.) 

•  How  we  sustain  the  force  (our  ability  to  supply,  service,  sustain  and  maintain  the  force.) 

•  How  we  structure  the  force  (our  ability  to  organize  forces  with  the  a  mix  of  combat,  combat  support,  and 
combat  service  support  units.) 

Many  of  the  necessary  changes  have  already  been  identified  in  the  Quadrennial  Defense  Review  and  the 
report  of  the  National  Defense  Panel.  The  Defense  Reform  Initiative  is  a  welcome  and  long-overdue  serious 
and  energetic  effort  to  produce  substantial  improvement  in  the  operation  of  the  Department  by  streamlining 
organizations  for  agility,  investing  in  people,  exploiting  information  technology,  and  by  breaking  down 
barriers  between  organizations. 

However,  the  attainment  of  the  degree  of  jointness  demanded  by  Joint  Vision  2010  will  require  substantially 
greater  change  throughout  the  enterprise  than  apparently  is  presently  contemplated.  Major  changes  will  also 
be  required  in  such  fundamental  areas  as  industrial  policy,  the  current  acquisition  system,  to  include 
particularly  major  changes  in  program  management  policy,  and  similar  enterprise-wide  activities.  To  restate 
the  point  made  earlier:  there  is  no  point  is  solving  the  interoperability  problem  for  the  combat  forces  unless 
that  solution  is  extended  to  the  support  forces  as  well.  Light,  agile,  and  lethal  combat  forces  are  of  no  value  if 
they  are  tied  to  the  logistical  support  forces  of  today. 

JOINT  INTEROPERABILITY  IS  MANDATED 

DoD  Regulation  4630.8,  Information  Interoperability  (draft)  mandates  that: 

a.  All  systems  shall  be  considered  for  JOINT  use. 

b.  Interoperability  requirements  shall  be  reflected  in  the  requirements  documents  and  approved  by  the  Joint 
Staff. 

Systems  shall  be  tested  and  certified  for  JOINT  interoperability  prior  to  production  and  fielding. 


HOW  IS  INTEROPERABILITY  ACHIEVED? 


It  is  generally  agreed  that  interoperability  can  be  realistically  achieved  by  only  two  approaches:  black  box 
translators  and  the  implementation  of  an  Open  Systems  Process  (OS  Process). 

Black  Box  Translators.  The  black  box  approach  has  two  major  problems;  effectiveness  and  cost. 
Effectiveness  is  always  impacted  adversely  compared  to  an  integrated  solution,  and  costs  are  always  high. 
High  costs,  not  directly  evident  when  a  system  is  being  developed  or  acquired,  are  ultimately  experienced 
when  systems  are  required  to  be  maintained,  spared,  P3I'ed,  and  to  interoperate.  We  become  dependent  upon 
(and  are  at  the  mercy  of)  the  suppliers  of  the  original  system  who,  because  of  their  proprietary  position,  are 
the  only  qualified  entities  capable  of  provided  the  O&M  services  of  obsolete  technology  at  great  cost  and 
typically  well  behind  the  state-of-technology  in  the  private  sector.  Furthermore,  when  systems  are  required  to 
interoperate,  for  example  in  the  C3I  domain,  proprietary  "black  boxes"  have  to  be  developed  to  allow 
"proprietary"  systems  to  be  "marginally  interconnected".  As  one  system  is  changed,  by  virtue  of  its  being 
under  the  stewardship  of  an  owning  PM,  the  proprietary  "black  box"  must  be  changed  and  the  other 
"proprietary"  systems  must  also  be  changed  —  a  significant,  spiraling  cost  penalty  being  incurred  that  results 
in  little  to  no  added  value  to  the  end  user. 

The  Open  Systems  Process.  The  general  arguments  for  Open  Systems  (OS)  revolve  around  reductions  in 
"cost  of  ownership"  through  increased  competition  for  acquisition  of  technology  and  products  and  a  reduction 
in  the  hidden  costs  associated  with  industry  proprietary  technology  delivered  to  DoD  under  the  protecting 
umbrella  of  "we  are  different".  For  the  purposes  of  this  study,  however,  the  OSTF  believes  strongly  that  the 
military  capability  demands  of  Joint  Vision  2010  dominate  this  decision  space  and,  in  and  of  themselves, 
fully  justify  the  need  to  begin  a  rapid  DoD  transition  to  OS  now. 

Nevertheless,  “cost  of  ownership”  arguments  are  powerful  and  persuasive  and  add  great  weight  to  the 
imperatives  of  Joint  Vision  2010.  Today,  weapon  systems  cost  too  much  because  their  closed  designs  are 
based  on  nonstandard  interfaces  which  are  typically  supported  by  only  a  few  suppliers.  Having  only  a  few 
suppliers  limits  competition  which  tends  to  increase  costs,  and  risks  obsolescence  should  those  suppliers  fail. 
As  a  consequence,  today  DoD  faces  an  affordability  crisis  in  its  weapons  systems  life  cycle  costs.  Weapons 
systems  continue  to  be  developed  with  their  own,  often  unique  and  frequently  closed,  infrastructures,  making 
upgrading  or  modifying  them  over  their  expected  lifetime  of  20  to  40  years  both  problematic  and  expensive. 

An  OS  acquisition  process,  on  the  other  hand,  bases  the  weapons  system’s  design  on  Open,  commercially 
supported  interface  standards  with  the  prospects  of  a  large  supplier  and  customer  base.  Reduction  in  cost  of 
ownership  results  from  being  able  to  procure  and  maintain  systems  and  technology  "off-the-shelf1  from  the 
private  sector.  Cost  of  ownership  is  also  reduced  if  we  purchase  our  systems  in  such  a  manner  that  similar 
technology  is  used  in  multiple  systems  and  platforms.  Not  only  do  we  enjoy  volume  discounts,  but  we  also 
get  technology  reuse  across  the  various  systems,  thereby  reducing  the  cost  of  acquisition,  sparing,  and 
maintenance. 

Increased  competition,  and  the  resulting  decrease  in  acquisition  cost,  comes  about  by  virtue  of  the  definition 
of  "Open  Systems"  -  a  technology  or  product  supplied  by  multiple  vendors  that  adhere  to  a  set  of  stable 
standards  and  interface  specifications  that  exist  in  the  public  domain.  Furthermore,  by  leveraging  "Open" 
technology,  as  compared  to  reinventing  a  unique  version  for  each  and  every  system  we  procure,  implies  that 
we  can  invest  our  resources  for  DoD-specific  aspects  of  systems  being  procured.  Duplication  of  technology, 
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subsystems,  components,  etc.  is  minimized,  while  criticalDoD  resources  are  focused  on  needs  which  cannot 
be  satisfied  through  Open  COTS  products  and  technology.  At  a  DoD  corporate  level,  acquisition  resources 
that  are  presently  used  to  reinvent  and  reimplement  technologies  with  and  across  service  systems  would  be 
saved. 

Summary.  Although  there  are  several  ways  to  achieve  interoperability,  many  of  them  are  not  affordable.  As  a 
practical  matter,  therefore,  the  best  way  to  reach  this  objective  is  through  the  OS  Process.  The  OSTF  has  been 
briefed  on  several  current  programs  which  are  using  the  OS  Process  and  was  very  favorably  impressed  with 
three  which  could  well  serve  as  models  for  the  Department:  the  Intelligence  and  Electronics  Warfare 
Common  Sensor  (IEWCS),  the  Joint  Tactical  Radio  System  (JTRS)  Program  and  the  New  Attack  Submarine 
(NSSN)  Program. 

WHAT  ARE  SOME  OF  THE  BENEFITS  OF  AN  OS  PROCESS  IN  THE  COMMERCIAL  WORLD 
AND  WHAT  ARE  SOME  OF  THE  COMPANIES  SEEKING  THESE  BENEFITS? 

In  the  commercial  world,  the  benefits  that  justify  using  an  OS  Process  are  very  much  the  same  as  those  that 
would  accrue  to  the  Department:  interoperability,  reuse,  commonality,  affordability,  as  well  as,  application 
portability,  distributed  systems  architectures,  data  sharing,  scalability,  technology  innovation,  plus 
competitive  pricing  and  vendor  independence.  The  Department  is  not  the  only  organization  which  is  faced 
with  shrinking  budgets  and  changing  business  environments.  Examples,  of  some  of  the  companies  that  have 
elected  to  use  an  OS  Process  are  many  and  varied  (universities,  automotive  retailers,  construction,  State 
government,  railways,  software  vendors,  environmental  vendors  plus  the  US  Navy),  are  shown  below: 

1.  Ohio  Department  of  Natural  Resources  -  Implemented  a  Geographic  Information  Management 
Systems  (GIMS)  based  on  an  OS  approach.  The  system  uses  a  variety  of  computer  platforms  and 
application  software,  operating  over  a  sophisticated  computer  network.  The  implementation  of  GIMS  in 
an  “Open”  distributed  computing  environment  was  only  possible  through  the  wide  use  of  information 
standards.  The  “standards”  helped  facilitate  data  capture,  translation,  exchange,  and  documentation. 

2.  UNISYS  Integrated  Information  Environment  OS  Process.  Unisys  describes  their  experience  in  moving 
to  an  OS  Process  as  follows: 

“To  Unisys,  Open  means  combining  the  hardware  and  software  products  from  different 
vendors  to  form  a  seamless  information  network  that  is  aligned  with  vendor  neutral  or 
independent  standards.  The  key  to  fulfilling  information  technology  requirements  in 
interoperability.  Interoperability  is  the  ability  to  bridge  from  the  hardware  and  software 
components  of  one  vendor  to  the  hardware  and  software  components  of  another  vendor.  By 
creating  a  seamless  information  infrastructure  that  delivers  information  “on  demand,” 
interoperability  helps  an  enterprise  concentrate  on  its  business  processes,  decision  making, 
and  customer  service.  Unisys  is  committed  to  the  idea  that  an  enterprise  should  be  free  to 
focus  on  implementing  its  business  strategy  and  not  on  interconnecting  incompatible 
hardware  and  software.  OS  and  standards  are  the  key  to  achieving  this  goal.  They  provide  an 
enterprise  with  the  flexibility  it  needs  to  build  information  systems  from  the  technology  that 
best  meets  it  needs,  regardless  of  vendor.” 
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Unisys  required  a  system  that  permitted  its  users  to  exchange  information  and  be  able  to  interpret  and  act 
upon  that  information,  regardless  of  the  manufacturer.  The  architecture  of  the  system  should  document 
the  industry  standards  and  information  technologies  the  enterprise  has  already  adopted  as  well  as  any  new 
or  emerging  standards  and  technologies  that  the  enterprise  wants  to  integrate  into  its  existing  network.  Its 
OSA  identified  the  need  for  its  users  to  access  and  for  the  enterprise  to  manage,  information  that  resides 
on  different  platforms  and  at  physically  remote  locations. 

3.  ALLDATA  Corporation  -  The  automotive  industry  has  numerous  standards  to  insure  that  things  work 
together.  For  example,  companies  that  manufacture  wrenches,  companies  that  manufacture  bolts  and 
companies  that  manufacture  automobiles  all  comply  with  a  set  of  standards  for  bolt  dimensions.  The  bolt 
manufacturer  complies  with  a  standard  that  clearly  defines  the  bolt  head,  length,  width,  thread  and 
strength  requirements.  Since  these  standards  are  accepted,  the  wrench  company  can  make  a  wrench  that 
can  be  used  on  the  same  type  of  bolt  regardless  of  who  the  bolt  manufacturer  is.  The  automobile 
manufacturer  can  use  this  standard  bolt  from  a  wide  range  of  vendors,  get  competitive  pricing  and  know 
that  their  tools  can  be  used  on  this  bolt.  In  essence,  an  OS  Process  allows  you  the  freedom  to  choose, 
while  still  getting  the  greatest  value  for  your  money. 

4.  Hermes  -  The  Hermes  community  is  committed  to  implementing  OS  solutions  for  freight  and  passenger 
applications  between  the  Hermes  railways.  At  the  heart  of  this  commitment  is  an  affirmative  commercial 
strategy  for  reducing  costs,  portability  of  applications,  interoperability  of  IT  products  and  components 
within  and  across  enterprises,  scalability  of  systems  implementation,  and  reduction  in  obsolescence  and 
future  proofing.  It  is  in  the  long  term  interest  of  both  the  Hermes  community  as  a  whole  and  the 
individual  Hermes  railways  to  adopt  information  technology  and  communications  infrastructure  that 
optimizes  operational  effectiveness  and  commercial  viability,  and  to  reach  outward  to  provide  services  to 
non-railway  organizations  and  connect  with  new  railways.  This  can  be  accomplished  using  an  OS 
solution.  It  is  generally  recognized  that  the  adoption  of  OS  solutions  is  intimately  linked  to  the  future  of 
the  Hermes  community  as  a  whole  and  that  of  the  individual  railways.  The  concept  of  OS  is  founded  on 
interoperability  between  systems,  not  between  system  components. 

5.  Trafalgar  House  Construction  -  UK-based  Trafalgar  House  Construction  has  implemented  a  multi¬ 
million  pound  OS  strategy  affecting  all  areas  of  its  business.  With  over  150  systems  being  installed  at 
permanent  and  temporaiy  office  and  construction  sites  in  the  UK  and  worldwide,  Trafalgar  House  was 
looking  for  an  OS  strategy.  A  strategy  which  offers  interoperability,  so  that  computers  from  different 
vendors  can  communicate;  scalability,  so  that  systems  can  grow;  portability,  so  that  applications  can  be 
transferred  to  run  on  different  machines;  and  consistent  operation,  so  that  from  both  a  user  and  systems 
administration  point  of  view  all  systems  within  the  company  are  the  same.  They  used  to  manage  their 
system  with  a  staff  of  60  and  now  having  implemented  an  OS  solution  that  can  manage  the  network  with 
a  staff  of  45  even  through  the  network  and  number  of  systems  has  grown. 

6.  The  Colt  Group  -  A  UK-based  company  specializing  in  designing,  .manufacturing  and  installing 
industrial  and  commercial  environmental  control  systems.  Colt  decided  to  revamp  its  information  systems 
using  an  OS  Process.  Colt  identified  several  key  elements  of  its  new  policy;  to  enter  and  store  data  only 
once;  to  have  a  single  User  Interface  allowing  common  access  to  all  applications;  to  eliminate  the  use  of 
custom  or  handmade  software;  and  to  facilitate  easy  inter-site  communications.  This  strategy  was  based 
upon  developing  a  Colt  system  from  standard  “Open”  elements  and  then  deploying  an  appropriately 
scaled  and  configured  version  at  each  Colt  location. 
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YES,  WE  DO  CARE! 


Of  the  several  capabilities  which  we  must  develop  to  ensure  continued  U.S.  military  superiority  in  the  21s* 
century,  two  loom  particularly  large:  the  vastly  improved  interoperability  which  will  be  required  to  maintain 
and  improve  the  combat  power  of  the  smaller,  lighter,  more  agile  forces  of  the  future,  and  the  much  improved 
affordability  of  future  forces  that  will  make  possible  their  continual  modernization  within  what  are  likely  to 
be  level  budgets. 

There  are  some  who  criticize  the  Department  today  for  what  they  consider  to  be  its  insatiable  desire  for  glitzy, 
high  tech  weapon  systems  despite  the  absence  of  what  they  consider  to  be  a  concomitant  threat. 

The  Task  Force  stands  in  strong  opposition  to  that  view.  WE  ARE  NOT  INTERESTED  IN  PUTTING  OUR 
CHILDREN  OR  GRANDCHILDREN  INTO  A  FAIR  FIGHT.  If  the  national  interests  of  the  United  States 
are  to  be  served  in  this  new  and  uncertain  future,  we  have  a  high  obligation  to  them  to  ensure  that  they  are 
provided  with  the  best  possible  weapons  systems — weapons  systems  which  will  enable  them  to  dominate  any 
future  conflict  and  bring  it  to  a  quick  and  favorable  solution  with  a  minimum  loss  of  life.  Perhaps  the  single 
most  important  step  we  must  take  to  make  that  vision  a  reality,  given  our  shrinking  budget,  is  by  means  of  an 
OS  solution  to  interoperability. 
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APPENDIX  E 


A  PERSPECTIVE  ON  ISSUES  ASSOCIATED  WITH 
IMPLEMENTING  OPEN  SYSTEMS 

by  Shawn  Butler,  Larry  Druffel,  Jeff  Harris,  and  Patrick  Winston 


DoD  operates  in  a  systems-of-systems  environment. 

DoD  acquires  systems  that  are  both  composed  of  multiple  components  (subsystems)  and  are 
themselves  part  of  larger  systems.  Just  as  the  user  operates  in  the  context  of  a  larger 
organizational  context  requiring  interaction  with  others,  the  system  also  must  operate  in  a  larger 
context  and  be  capable  of  interoperating  with  other  systems. 

In  a  system  acquisition,  the  objective  is  to  acquire  a  capability  that  meets  functional  (warfighting) 
requirements.  In  addition  to  these  functional  requirements  for  warfighting,  the  system  must 
exhibit  non-functional  attributes  that  stem  from  the  context  in  which  it  is  to  operate.  Examples  of 
these  attributes  include  the  need  for  interoperability  with  other  components,  portability  across 
platforms,  and  supportability  of  the  system  through  its  lifecycle,  with  affordability  becoming  an 
increasingly  important  driving  factor.  These  non-functional  attributes  “ilities”  are  just  as 
important  as  the  functional  requirements  and  may  dominate  the  decision  process. 

One  way  to  get  a  handle  on  the  complex  issues  raised  by  the  Open  Systems  (OS)  concept  is  to 
think  in  terms  of  three  levels:  the  warfighting  level,  the  technical  level,  and  the  business  level. 

The  functional  requirements  and  essential  attributes  are  defined  at  the  warfighting  level.  To 
achieve  the  warfighting  requirements,  additional  attributes  will  be  introduced  at  the  technical 
level.  Finally,  other  attributes  will  be  introduced  at  the  business  level.  Some  aspect  of  an 
attribute  may  be  imposed  at  all  three  levels,  for  different  reasons.  It  is  useful  to  be  clear  about  the 
level  at  which  the  requirement  for  an  attribute  is  introduced  so  that  an  attribute  at  a  lower  level 
not  conflict  with  an  attribute  at  a  higher  level.  This  needs  to  be  an  iterative  and  interactive 
process,  not  a  strictly  hierarchical  one. 

The  context  for  the  system  and  the  attributes  it  is  to  exhibit  should  be  defined  by,  but  not 
necessarily  limited  to,  the  operational  architecture  and  should  be  supported  in  the  system 
architecture  and  the  technical  architecture.  To  the  extent  that  these  are  not  made  explicit,  they 
should  be  derived  and  priorities  determined,  recognizing  that  attributes  may  be  in  conflict  that 
must  be  resolved  as  part  of  the  engineering  tradeoff  analysis. 

For  systems  involving  computer  hardware  and  software,  DoD  is  finding  that  use  of  commercial 
products  and  standards  offer  an  attractive  alternative  to  developing  a  military  unique  system. 
While  commercial  products  seldom  precisely  meet  the  full  set  of  functional  requirements,  they 
may  still  be  attractive  if  the  user  is  prepared  to  adapt  the  requirements  to  commercial  offerings. 
For  more  complex  systems,  integration  of  several  commercial  products  often  provides  a  very 
attractive  option  for  achieving  the  attributes.  Indeed  the  commercial  world  has  refined  this 
approach  into  an  “OS”  strategy  for  more  easily  integrating  components  into  a  system  to  achieve 
the  non-functional  attributes,  particularly  affordability. 
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OS  is  not  the  objective.  The  objective  is  to  acquire  and  sustain  a  capability  that  is  defined  by 
warfighting  requirements  and  that  exhibits  certain  attributes  that  support  the  derived  technical  and 
business  considerations.  When  combined  with  other  commercially  motivated  strategies,  OS  is  a 
means  to  achieving  an  implementation  of  a  needed  capability.  In  the  ideal,  it  provides  a  strategy 
for  assembling  components  into  a  system  (and  systems  into  a  system  of  systems),  often  described 
as  plug  and  play. 

Characteristics  of  OS  and  their  contribution  to  achieving  non-functional  attributes 
(“ilities”). 


While  there  are  a  variety  of  definitions  of  OS  that  often  lead  to  non-productive  debate,  it  is  more 
useful  to  consider  the  characteristics  of  OS  and  consider  how  these  characteristics  affect  our 
ability  to  achieve  the  non-functional  attributes. 

Interoperability:  We  are  interested  in  whether  components  can  interact  as  well  as  the  costs  or 
efforts  to  get  them  to  interact.  The  definition  of  interoperability  (The  capability  for  two  or  more 
components  to  interact)  overlooks  the  questions  of  cost  and  effort.  In  light  of  this,  we  define 
interoperability  as  the  potential  for  two  or  more  components  to  share  information. 

The  interoperability  system  attribute  can  be  both  a  functional  and  non-functional  requirement.  It 
is  a  functional  requirement  because  requirement  documents  often  specify  that  certain  components 
must  interoperate.  It  is  a  non-functional  attribute  because  in  general  we  want  systems  that  can 
interoperate  with  other  unspecified  systems.  Although  interoperability  is  difficult  to  test,  the  use 
of  standards,  COTS  and  modular  design  reduces  the  amount  of  effort  needed  to  achieve 
interoperability. 

Portability:  The  potential  for  a  system  to  operate  on  different  platforms.  Portability  is  achieved 
through  design  and  standards.  Standards  are  used  to  minimize  the  differences  among  different 
platforms.  When  standards  can’t  support  the  implementation  then  the  system  design  must 
minimize  the  system’s  reliance  on  proprietary  interfaces  and  extensions.  Portability  is  a  non¬ 
functional  requirement  because  we  cannot  always  anticipate  the  platforms  on  which  components 
will  operate.  For  example,  when  Joint  Maritime  Command  Information  System  (JMCIS)  was 
built,  the  program  manager  never  anticipated  that  JMCIS  components  would  run  on  the  variety  of 
platforms  that  they  do  today.  However,  if  the  program  manager  had  specified  that  JMCIS  must 
be  portable  enough  to  run  on  three  top  selling  hardware  platforms,  he  would  have  been  thought 
crazy.  A  measure  of  system  portability  is  the  level  of  effort  required  for  a  system  to  work  on 
multiple  platforms.  The  penalty  of  maintaining  system  portability  is  that  it  can  increase  system 
supportability  costs. 

Scalability:  We  define  scalability  as  the  potential  for  a  system  to  grow  and  accommodate  more 
and  more  users,  or  additional  functionality.  As  systems  are  interconnected  and  more  and  more 
information  is  shared  among  different  levels  of  operations,  it  is  essential  that  the  systems  built 
today  can  handle  the  additional  stress  of  these  interactions.  As  expectations  change  about  what 
our  current  systems  capabilities  should  be,  a  scalable  system  can  absorb  the  growth. 
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Supportability:  Supportability  can  be  defined  as  “the  actions  related  to  the  reliability, 

maintainability,  and  affordability  of  component  implementations,  and  the  integrated  logistics 
support  and  configuration  management  required.”  1  Reliability  can  be  tested  and  is  usually  a 
functional  requirement.  Maintainability  and  affordability  are  difficult  to  test,  but  highly  desirable 
system  properties.  Maintainability  is  a  function  of  software  design  such  as  modularity  and 
abstraction,  and  good  software  engineering  practices  such  as  described  in  the  Capability  Maturity 
Model  or  ISO  9000.  Using  standards  and  COTS  products  leverages  affordability.  COTS 
products  reduce  the  need  for  customized  development.  This  reduced  need  allows  amortized  cost 
of  new  functionality  across  a  greater  customer  base. 

Performance:  Performance  is  the  capability  of  a  system  to  meet  requirements.  Performance  is  a 
system  attribute  that  is  normally  specified  in  requirement  documents,  however,  it  is  unique 
because  requirements  may  be  met  at  the  cost  of  supportability,  portability,  or  another  system 
property.  For  example,  real  time  system  requirements  may  dictate  customized  software. 
Customized  software  decreases  system  supportability. 

These  are  only  some  of  the  characteristics  of  Openness.  One  can  see  from  this  small  subset  that 
some  of  these  attributes  conflict.  The  program  manager’s  job  is  to  find  the  appropriate  balance 
among  the  characteristics,  knowing  that  as  performance  requirements  increase,  the  system  could 
become  less  open. 

One  reason  to  achieve  Openness  is  to  reduce  the  cost  of  making  changes  to  the  systems  when 
unanticipated  requirements  dictate.  A  common  thread  throughout  each  of  the  descriptions  is  that 
the  degree  to  which  a  characteristic  contributes  to  the  Openness  of  a  system  depends  not  only  on 
its  contribution  when  building  the  system  but  equally  on  its  contribution  to  the  ease  with  which  a 
system  can  be  modified  or  maintained.  Scalability  is  not  a  requirement  unless  the  system  must 
grow.  Portability  is  not  a  requirement  unless  the  system  must  work  across  multiple  platforms. 
These  Openness  characteristics  become  important  at  various  stages  in  the  software  development 
cycle.  Scalability  and  portability  are  desirable  because  there  is  empirical  evidence  to  show  that 
systems  do  need  to  be  scalable  and  portable,  and  the  cost  to  achieving  these  attributes  increases 
as  the  system  matures. 

This  means  that  the  program  manger  must  balance  all  system  stakeholder  requirements. 
Stakeholders  are  the  warfighters,  acquisition  specialists,  maintainers,  and  vendors.  Each 
stakeholder  places  different  and  sometimes  competing  demands  on  the  program  manager.  The 
program  manager’s  job  is  to  maximize  system  capability  within  the  resources  allocated.  The 
program  manager  does  this  by  leveraging  OS  characteristics.  These  characteristics  are  essential 
to  a  system  if  the  program  manager  is  trying  to  maximize  the  requirements  with  the  system 
functionality.  These  “ilities”  are  the  key  to  leveraging  warfighter  functionality. 

Standards  and  software  design  achieve  almost  all  of  the  OS  attributes.  Standards  have  received 
the  most  emphasis  because  they  are  concrete  and  testable.  Design  characteristics  are  more 
subjective  because  it  is  difficult  to  quantify  why  one  design  is  more  scalable  than  another,  or  why 
one  design  is  more  supportable  than  another.  There  a  small  metrics  that  give  software  engineers 
insight  about  the  characteristics,  but  evaluation  of  software  designs  are  usually  left  to  experienced 
software  architects  and  engineers.  In  general,  the  more  robust  and  flexible  a  design  the  more 
Open  the  system.  Similarly,  as  standards  are  selected  based  on  their  commercial  support  and 


1  Open  Systems:  The  Promises  and  the  Pitfalls,  Meyers  and  Obemdorf,  Carnegie  Mellon  University,  1997. 
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public  acceptance,  the  more  Open.  Although  software  design  is  difficult  to  evaluate  with  respect 
to  OS,  it  is  as  significant  as  standards  in  its  contribution  to  OS. 

System  design  and  implementation  should  be  guided  by  an  architecture  defined  and 
managed  at  the  level  that  has  authority  over  all  the  systems  affected. 

To  achieve  the  attributes  (“ilities”),  the  operational,  systems,  and  technical  architectures  must  be 
defined.  The  technical  architecture  must  bind  those  elements  which  are  essential  to  achieving  the 
desired  attributes  and  leave  unbound  those  elements  that  are  not  essential  to  achieving  the  desired 
attributes.  While  this  is  easy  to  say,  it  is  difficult  to  define.  It  requires  considerable  judgement 
based  on  knowledge  of  the  domains  to  be  covered.  These  decisions  guide  the  way  in  which  the 
systems  are  to  be  made  Open. 

Definition  and  control  of  the  architecture  must  be  vested  at  that  level  which  has  authority  over  all 
the  systems  affected  by  the  architecture.  This  principle  has  lead  to  the  suggestion  that  the 
architecture  can  be  defined  as  a  top  down  strategy  with  refinements  at  each  level.  It  has  been 
suggested  that  a  natural  conclusion  of  this  strategy  is  that  the  architecture  of  the  higher  level 
system  would  stop  at  the  skin  of  the  platform.  While  this  is  desirable  and  appropriate  for  some 
elements  of  the  architecture,  the  complexity  of  interaction  among  the  various  attributes  makes  it 
impractical.  The  following  two  examples  illustrate  this  point. 

The  first  example  stems  from  the  realization  that  while  a  platform  has  an  essential  warfighting 
function,  it  may  also  be  host  to  some  other  warfighting  function  that  is  incidental  to  its  main 
purpose  but  which  is  important  to  the  context  in  which  it  is  to  operate.  The  intelligence  function 
is  a  good  case.  Various  platforms  that  will  engage  in  a  specific  operation  carry  a  variety  of 
sensors  that  may  collect  information  for  its  primary  purpose.  That  same  information  may  be 
valuable  from  an  intelligence  perspective.  While  the  principal  function  of  the  platform  may 
constrain  the  use  of  the  information  at  specific  times  such  as  the  requirement  to  remain  passive  to 
support  stealth,  at  other  times  the  information  may  be  safely  transmitted  without  affecting  the 
primary  purpose.  That  component  of  the  system  supporting  intelligence  should  conform  to  the 
architecture  defined  and  controlled  by  the  intelligence  function. 

A  second  example  involves  the  case  of  supportability.  To  increase  the  supportability  of  a  family 
of  systems,  the  form,  fit  and  function  might  be  dictatedby  a  higher  level  authority  to  ensure  ease 
of  replacement  or  interchangibility.  Alternatively,  a  higher  authority  may  decide  that  all  systems 
under  its  purview  will  use  a  specific  database  system  that  supports  access  for  real  time  systems. 

These  are  only  examples.  There  are  undoubtedly  other  instances  in  which  the  system  in  which 
the  new  system  is  to  operate  will  constrain  the  architectural  decisions.  This  is  certainly  not 
popular  with  program  managers  who  would  prefer  the  autonomy  that  their,  predecessors  enjoyed 
in  the  days  when  we  built  stovepipe  systems.  However,  it  is  the  nature  of  the  engineering  process 
in  which  constraints  are  placed  on  design.  It  is  important,  therefore,  that  these  higher  level 
architectures  bind  only  that  which  needs  to  be  bound  to  achieve  the  purpose  and  not 
overconstrain  the  design  space. 

It  is  tempting  to  recommend  that  the  architectural  controls  be  defined  and  managed  at  the  highest 
level,  which  would  then  make  the  entire  defense  system  one  enormous  system-of-systems. 
Implementing  such  a  recommendation  would  be  impractical  for  technical  and  cultural  reasons. 
At  the  technical  level,  the  diversity  of  systems  and  the  complexity  of  the  various  attributes  makes 
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the  technical  feasibility  questionable.  Secondly,  there  are  simply  too  many  variables  to  expect 
individuals  to  accommodate  the  level  of  complexity  that  would  be  introduced.  Finally,  it  would 
require  a  fundamental  shift  in  the  overall  organization  that  is  probably  not  warranted. 

There  is,  however,  a  practical  level  at  which  this  strategy  can  be  implemented  within  the  current 
structure.  The  PEO  structure  generally  covers  the  domains  over  which  operational,  systems  and 
technical  architectures  would  be  both  tractable  and  logical.  Therefore,  we  recommend  that  the 
PEOs  be  treated  as  product  line  managers.  They  should  be  provided  the  funding  and  authority  to 
define  and  manage  the  systems  architecture  and  technical  architecture  over  their  systems.  They 
are  in  a  position  to  work  with  their  warfighting  customers  to  develop  the  operational  architecture 
and  to  make  the  decisions  necessary  to  trade  the  attributes  against  the.  specific  system 
performance  and  functional  capabilities. 

While  practical,  this  recommendation  is  not  ideal.  First,  the  PEOs  are  aligned  along  Service 
lines.  Therefore,  architectures  for  those  domains,  such  as  the  aircraft  and  avionics  architectures 
which  could  be  common  to  the  three  services,  will  not  necessarily  be  consistent.  Likewise, PEOs 
—  making  valid  technical  and  business  decisions  with  their  respective  program  managers  ~  will 
undoubtedly  choose  standards  and  products  that  are  inconsistent  with  those  of  other  systems  over 
which  commonality  might  be  important.  In  some  cases,  such  as  C^I,  there  is  existing  structure 
and  progress  toward  a  joint  technical  architecture.  Similar  joint  efforts  might  be  mounted  for 
other  domains. 

One  idea  presented  to  the  OSTF  that  should  be  considered  is  to  develop  a  resource  to  maintain 
visibility  into  the  choices  of  standards  and  products  being  made  for  each  of  the  technical 
architectures.  Supported  by  a  rich  database,  this  function  could  identify  when  technical 
architectures  are  choosing  incompatible  standards  and  also  maintain  a  community  of  interest  in 
specific  standards  and  products.  This  should  be  a  monitoring  and  alerting  function  and  a 
resource  to  the  PEOs.  It  should  not  have  authority  to  control. 

OS  is  not  a  binary  decision  that  is  implemented  uniformly  throughout  a  system.  It  must  be 
based  on  a  clear  vision  of  the  objective  capabilities  needed. 

Through  the  process  of  systems  design,  various  components  are  defined.  For  each  component 
and  its  interface,  a  variety  of  design  decisions  must  be  made.  Among  those  decisions  should  be 
the  degree  to  which  that  component  will  be  made  Open.  While  the  decision  process  should  be 
guided  by  a  consistent  set  of  principles,  different  components  of  an  “Open”  system  may  be 
closed.  This  section  ■will  consider  some  of  the  decision  criteria  that  might  be  used  to  guide  that 
process. 

The  context  for  the  design  decision  process  is  set  by  the  overall  architecture  (operational 
architecture,  the  systems  architecture  and  the  technical  architecture).  These  three  architectural 
views  traditionally  have  not  been  made  explicit  within  DoD.  There  are  efforts  underway  to 
address  them  within  the  C4ISR  community.  The  greatest  progress  seems  to  be  with  the  Joint 
Technical  Architecture.  While  this  is  an  important  start,  a  technical  architecture  without  an 
operational  and  systems  architecture  provides  too  little  guidance  to  the  design  process. 

Ideally,  there  would  be  a  hierarchy  of  architectural  descriptions  with  a  responsible  chief  architect 
at  each  level.  The  chief  architect  at  each  level  would  provide  guidance  to  subordinate  levels  that 
would  guide  the  design  decisions  including  the  extent  to  which  a  specific  component  needs  to  be 
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Open.  Absent  that  guidance,  the  chief  architect  for  the  system  must  make  his/her  own  best  guess 
based  on  an  understanding  of  the  non-functional  attributes.  When  a  systems  architect  is  not 
provided  an  architectural  context  in  which  to  operate,  he/she  must  be  particularly  sensitive  to 
these  questions.  While  the  system  may  not  need  Openness,  other  systems  in  the  context  it  shares 
may  demand  it. 

As  each  component  is  defined,  whether  that  component  is  to  be  implemented  in  hardware  or 
software,  the  architect  should  consider  the  following  questions. 

Can  the  required  functionality  (or  some  major  component  of  it)  be  realized  by  using  a 
commercial  product  or  standard?  In  an  ideal  world,  system  decomposition  would  follow  a  top- 
down  process  driven  solely  by  the  system  requirements.  However,  in  today’s  computer  systems 
environment,  a  bottom-up  driven  process  of  assembling  existing  components  has  higher  leverage 
than  ab  initio  development.  Therefore,  the  first  practical  question  should  be  whether  an  existing 
product  meets  a  sufficient  portion  of  the  system  requirements  to  be  considered  and  whether  an 
existing  standard  will  support  the  requirements.  This  question  must  be  addressed  in  an  overall 
architectural  context. 

The  benefits  that  may  be  achieved  by  incorporating  existing  products  and  standards  are  so 
powerful  that  it  warrants  consideration  of  modifying  the  requirements  to  fit  an  available  product. 
While  this  has  not  been  accepted  practice  in  the  DoD,  user  stated  requirements  have  varying 
priorities.  The  opportunity  to  use  an  existing  product  or  standard  should  not  be  rejected  until  the 
importance  of  unsupported  requirements  is  given  careful  consideration  and  the  user  makes  the 
priorities  clear  and  understands  when  a  requirement  is  a  driving  the  decision  to  be  closed. 

Is  the  information  generated  by  this  module  important  to  any  other  element  in  the  larger  system 
of  systems  context  (or  likely  to  be  so  in  the  future)?  If  so,  then  the  information  needs  to  be 
communicated  and  the  means  of  communication  decided.  If  the  information  is  needed  or  might 
conceivably  be  needed  in  the  future,  then  the  component  is  a  candidate  to  be  Open. 

This  question  of  possible  future  need  deserves  more  consideration  at  this  time  in  DoD.  At  this 
stage  of  our  system-of-systems  development,  we  are  faced  with  a  legacy  of  stovepiped  systems. 
For  a  variety  of  reasons,  current  Service  doctrine  would  not  accommodate  making  information 
available  to  other  systems.  But  evolving  visions  such  as  Joint  Vision  2010  require  that  doctrine 
be  reconsidered.  DoD  system  architects  certainly  do  not  want  to  define  systems  that  would  make 
it  technically  difficult  to  respond  to  changing  doctrine.  Therefore,  a  component  that  might 
otherwise  not  need  to  be  Open  might  very  well  be  made  Open  simply  to  accommodate  a  future 
system-of-systems  capability. 

Is  this  component  likely  to  be  replaced  in  the  future?  Reasons  for  possibly  replacing  a  unit  in  the 
future  might  include  an  assessment  that: 

•  The  underlying  technology  is  changing  -  for  example,  a  chipset  might  eventually  replace 
a  group  of  chips; 

•  A  commercial  product  that  would  meet  the  need  is  maturing  and  would  be  available  in 
the  future; 

•  The  functional  capability  being  supported  could  change  -  for  instance,  a  component  that 
processes  data  from  a  specific  sensor  would  change  if  the  sensor  is  changed  or  replaced; 
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The  component  is  susceptible  to  replacement  during  repair. 


Is  there  an  opportunity  for  developing  common  modules  for  similar  systems?  This  question 
should  be  asked  even  for  systems  that  are  military  unique  where  the  DoD  must  pay  the  entire 
cost,  including  duplicate  investments  by  related  programs.  The  DoD  has  already  demonstrated 
significant  cost  savings  and  reduced  time  to  market  following  this  strategy.  The  Army  IEWCS 
and  Air  Force  PRISM  programs  are  two  examples. 

While  there  are  a  number  of  reasons  why  a  component  should  be  Open,  not  every  component  in 
an  OS  needs  to  be  Open.  When  the  decomposition  reaches  a  point  where  the  details  of  the 
implementation  are  no  longer  of  concern  to  the  architect  at  any  higher  level,  and  answers  to  the 
previous  questions  are  negative,  then  a  closed  solution  should  be  acceptable.  If  functionality  is 
unique  to  the  system  or  so  unique  to  the  military  that  no  commercial  product  is  likely  to  become 
available,  a  closed  component  may  be  the  most  expeditious.  Likewise  for  some  essential 
components  such  as  real  time  control  systems,  performance  considerations  may  dominate  all 
other  considerations,  including  Openness.  In  summary,  an  OS  may  have  completely  closed 
components  or  components  that  are  less  Open  due  to  a  proprietary  implementation. 

How  do  we  select  standards  to  achieve  the  benefits  of  OS. 

OS  goals  are  achieved  through  a  process  of  technical  and  system  architecture  development.  Part 
of  that  process  is  to  select  the  standards  that  are  appropriate  for  the  system.  The  system 
architecture  is  the  context  for  selecting  the  standards.  Software  engineers  select  standards  on  the 
basis  of  their  applicability,  maturity,  and  degree  of  adoption  by  the  development  community  at 
large.  The  Joint  Technical  Architecture  provides  a  list  of  standards  that  meet  the  last  two  criteria; 
however,  system  engineers  must  select  the  applicable  standards.  Standards  selection  is  easy  if 
existing  systems  dictate  the  interfaces  or  if  the  standard  is  an  obvious  choice  because  not 
selecting  it  is  counterproductive. 

Imagine  the  implications  of  not  selecting  Microsoft  Windows  or  NT  for  the  PC.  There  are  other 
products  available  for  the  PC,  but  most  products  depend  on  the  Microsoft  environment.  A  choice 
other  than  Windows/NT  would  limit  the  selection  of  other  COTS  products  thereby  increasing 
development  costs.  Experienced  developers  would  be  scarce;  increased  development  would  be 
costly.  Legacy  application  integration  would  be  extremely  expensive,  if  not  impossible. 
Following  such  a  decision,  administrators  would  need  specialized  training  once  the  system  is 
fielded.  Follow-on  maintenance  costs  would  be  at  a  premium  since  developers  could  command  a 
veiy  high  price.  Although  this  example  may  be  extreme  it  illustrates  some  of  the  costs  of  not 
following  the  “building  codes.” 

The  difficulty  in  selecting  standards  arises  when  the  choices  are  not  obvious.  Four  conditions  can 
make  decision  making  difficult:  (1)  when  a  standard  has  not  matured,  (2)  when  proprietary 
extensions  are  necessary  for  performance  requirements,  (3)  when  multiple  standards  exist  for  the 
same  component,  or  (4)  when  a  standard  does  not  exist. 

A  standard  has  not  matured.  A  specification  exists,  but  either  products  have  not  been  created 
or,  if  the  product  has  been  created,  the  product  has  not  been  tested  in  an  adequate  number  of 
contexts.  An  example  of  this  situation  is  the  Common  Object  Request  Broker  Architecture 
(CORBA).  The  specification  preceded  an  implementation.  As  products  became  available  and 
the  specification  was  tested,  it  quickly  became  obvious  that  CORBA  was  well  suited  for  some 
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applications,  but  not  appropriate  for  all  applications.  Within  the  DoD  there  was  considerable 
pressure  to  select  CORBA  as  the  middleware  for  software  systems.  Since  CORBA  is  not 
appropriate  for  all  applications,  settling  on  CORBA  as  the  standard  for  all  applications  would 
have  been  premature. 

Proprietary  extensions  are  needed.  The  specifications  may  be  complete,  but  do  not  support 
system  performance  requirements.  SQL  is  a  perfect  example  of  this  condition.  There  are  few 
developers  that  adhere  to  a  strict  implementation  of  SQL  because  they  cannot  get  the  database 
performance  necessary  to  meet  the  system  performance  requirements.  Developers  frequently 
depend  on  proprietary  extensions  that  cause  a  tighter  coupling  to  the  database  vendor  than  a  more 
OS  approach  would  dictate. 

Multiple  standards  exist.  Multiple  standards  can  meet  requirements,  but  an  engineering 
analysis  must  be  done  to  select  the  most  appropriate  product.  However,  the  decision  can  result  in 
losses  such  as  flexibility,  scalability,  or  can  result  in  increased  costs  down  the  road.  CORBA  and 
DCE  support  distributed  computing  and  both  are  acceptable  choices  within  the  JTA,  however, 
both  support  different  software  architectures.  Selecting  the  standard  before  the  software 
architecture  is  developed  forces  the  architecture  to  be  consistent  with  the  product,  instead  of 
selecting  the  architecture  because  it  is  the  best  fit  for  the  problem.  This  is  also  an  example 
demonstrating  that  standards  are  not  a  substitute  for  software  engineering. 

A  standard  does  not  exist.  System  design  may  call  for  a  specific  architecture  or  software 
component  that  does  not  have  an  existing  standard.  This  can  occur  because  the  product  is 
militarily  unique,  or  no  standard  exists  in  the  marketplace.  Messaging  and  queuing  products  do 
not  adhere  to  a  standard. 

No  decision  is  black  and  white.  Decision  makers  must  consider  the  desired  “ilities”  for  the 
system.  Decisions  must  be  made  considering  the  context  of  the  desired  system  properties. 

Systems  evolution  following  an  OS  strategy  requires  a  different  mindset  and  different 
approaches  than  the  traditional  DoD  Systems  acquisition. 

When  a  system  is  developed  following  an  OS  strategy,  a  number  of  issues  must  be  handled 
differently  than  for  traditional  development.  Among  the  issues  to  be  considered  are  the 
following. 

Program  Management  -  The  Program  Manager  in  the  OS  development  process  has  a  number  of 
competing  interests  that  need  to  be  balanced.  The  Program  Manager  needs  to  be  given  enough 
flexibility  to  make  parametric  trade-offs  on  what  are  seemingly  incompatible  criteria.  A  strong 
motivated  and  empowered  systems  architect  is  mandatory.  This  person  must  have  knowledge  of 
both  the  end-user  system  needs  and  knowledge  of  commercial  practices,  trends  and  importantly 
limitations.  In  DoD  the  system  acquisition  specialist  must  be  an  informed  and  educated  buyer. 
This  person  needs  to  establish  the  framework  for  trades  so  architecture  and  development 
decisions  can  be  responsibly  made  using  the  following  criteria: 

•  performance 

•  required  existing  and  future  functionality 

•  schedule 

•  flexibility  and  ease  of  evolution 
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•  vendor(s)  commitment  to  commercial  development 

•  multiple  vs  single  vendor  product  availability 

•  training  and  operation 

•  ease  of  evolution 

•  initial  and  life  cycle  costs 

•  complexity  of  middleware  software 

•  database  design 

•  required  interoperability 

Requirements  -  DoD  must  continue  the  evolution  to  user  statements  of  need.  System 
requirements  must  focus  on  the  what  and  limit  the  specific  specification  of  the  how.  Confusion 
about  this  will  unnecessarily  limit  the  flexibility  of  the  systems  designers  to  conduct  trades  that 
favor  a  more  OS  approach.  Where  appropriate,  the  systems  architect  should  be  allowed  to  look 
for  the  knee  in  the  performance  curve  and  recommend  the  80%  solution.  Significant  life-cycle 
resources  can  be  saved  if  the  80%  solution  is  judged  to  be  compliant  with  the  requirement. 

Development  Process  -  The  Program  Manager  and  systems  architect  must  recognize  that  better  is 
the  enemy  of  good  enough.  One  of  the  powerful  advantages  of  OS  is  it's  ability  to  incorporate 
evolving,  changing,  and  sometimes  conflicting  standards  and  products.  It  is  an  advantage 
because  when  chosen  properly,  the  standards  are  fueled  by  commercially  driven  development 
that  will  enhance  features,  connectivity  and  interoperability. 

Program  Managers  need  to  recognize  this  and  leave  the  relative  safety  of  custom  development 
and  move  to  the  building  block  approach  of  OS.  The  building  block  approach  is  manageable  but 
it  must  be  within  a  top-level  hardware  and  software  system  architecture  with  well  documented 
interfaces.  Middleware  and  graphical  user  interfaces  can  provide  transparent  complexity  to  the 
user  and  support  mediated  access  between  system  elements.  Caution  must  be  exerted  that  the 
DoD  fit-in  and  not  drive  the  standards  including  the  desire  to  always  be  cutting  edge.  Recognize 
that  when  properly  implemented  the  OS  approach  provides  the  opportunity  achieve  system 
improvements  through  evolution  as  the  building  blocks  of  the  system  evolve. 

Recognize  early  that  some  DoD  needs  will  not  be  met  with  commercial  items.  Design  a  process 
that  recognizes  this  early  and  does  not  over  anticipate  the  capabilities  of  commercial  Open 
solutions.  For  example,  security,  recoverability,  special  environments  and  hard  real-time  can  be 
drivers  beyond  the  scope  of  many  commercial  solutions.  Do  not  fall  trap  to  the  promise  of 
adaptability  of  a  commercial  stem  to  a  function  it  was  never  designed  to  do  and  the  marketplace 
will  not  support  its  long-term  support. 

Configuration  Management  -  The  Program  Manager  is  held  to  cost,  schedule  and  performance. 
The  custom  solution  is  a  powerful  siren's  call  given  these  pressures  because  the  Program 
Manager  -will  sense  improved  control.  To  the  contrary,  when  selected  properly  the  OS  elements 
allow  the  Program  Manager  to  get  started  with  tremendous  functionality  at  a  fraction  of  the  cost. 
Once  selections  are  made,  a  controlled  process  for  development  and  operation  must  be 
implemented.  The  systems  architect's  job  is  not  done. 

A  configuration  management  process  must  be  implemented  to  evaluate  the  impact  of  changes  that 
will  be  continually  thrown  at  the  program.  For  example,  the  promotion  process  of  new  versions 
of  software  products  will  require  structured  testing  to  validate  interfaces  to  middleware  before 
the  change  is  fielded.  A  structured  discrepancy  review  process  that  allocates  resources,  assigns 
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resources,  evaluates  fixes  and  maintains  configuration  of  the  overall  process  is  required.  This 
process  must  maintain  a  dialog  with  the  vendors  so  that  changes  can  be  better  anticipated  and  the 
vendors  can  receive  important  feedback  from  the  customers  of  their  systems. 

When  employing  the  OS  approach,  the  program  manager  must  be  prepared  to  keep  individual 
components  up  to  date  with  version  changes.  This  must  be  a  planned  process  that  recognizes  two 
important  three  important  factors.  There  will  be  continuing  costs  that  must  be  budgeted.  New 
versions  of  commercial  products  may  not  always  be  upward  compatible.  Two  different  products 
that  depend  on  the  same  underlying  third  product  may  assume  different  versions  of  that  third 
product. 

An  OS  strategy  requires  a  complementary  strategy  for  migrating  legacy  systems  to  become 
more  Open. 

Legacy  systems  are  a  special  challenge.  A  continual  review  of  the  state-of-the-art  must  be 
accomplished  so  the  migration  of  systems  can  be  managed  effectively.  The  resource  managers 
within  DoD  need  to  recognize  that  holding  on  to  the  past  can  significantly  increase  costs  and 
lower  performance.  An  OS  strategy  requires  a  complementary  strategy  for  migrating  legacy 
systems  to  become  more  Open. 

The  decision  whether  to  migrate  a  system  to  an  OS  really  depends  on  the  cost  effectiveness  of  the 
migration.  The  first  step  in  the  decision-making  process  is  identification  of  OS  properties.  The 
program  manager  must  decide  what  “ilities”  are  needed.  Following  this,  the  program  manager 
must  identify  the  best  method  for  achieving  these  “itities.”  This  type  of  analysis  can  prevent 
implementation  of  unnecessary  changes.  Since  the  program  manager  may  not  fully  grasp  the 
overall  system’s  complexities,  another  staff  person  with  oversight  ability  must  review  the  initial 
analysis.  The  analysis  may  show  that  system  migration  is  not  cost  effective.  Such  conclusions 
could  lead  to  a  decision  to  wait  and  replace  the  system  at  a  later  time. 

Several  strategies  can  apply  to  migrating  systems.  Although  some  strategies  can  be  identified,  not 
all  can  be  enumerated  because  each  situation  may  be  different.  Changing  the  entire  system  to 
adhere  to  standards  that  don’t  result  in  a  direct  benefit  to  those  “ilities”  is  not  cost-effective. 
The  key  question  is  how  to  anticipate  system  requirements.  There  is  no  easy  answer  to  this 
question.  It  is  much  easier  to  employ  these  principles  when  starting  from  scratch,  as  opposed  to 
importing  these  principles  into  existing  systems. 

Trade-offs  often  accompany  each  strategy  employed  to  migrate  systems.  For  example,  wrapping 
the  system  allows  encapsulation,  but  does  not  increase  supportability  or  modularity.  Wrapping 
the  system  may  increase  interoperability.  A  different  strategy  such  as  breaking  the  system  apart 
and  wrapping  individual  components  can  increase  modularity  and  component  reuse.  However,  if 
component  reuse  is  not  a  goal,  the  first  strategy  may  be  sufficient  and  would  cost  less. 

In  summary,  decision  making  regarding  migrating  systems  must  be  guided  by  system 
requirements  and  engineering  principles. 


page  10 


DSB  TASK  FORCE  ON  OPEN  SYSTEMS 
APPENDIX  F 


SUPPORTABILITY 

by  Tofie  M.  Owen,  Jr. 


INTRODUCTION 


Our  DSB  Task  Force  on  Open  Systems  (OSTF)  explored  the  issue  of  supportability  in  terms  of 
the  relationship  between  Open  Systems  (OS)  and  the  vision  of  focused  logistics  as  expressed  in 
Joint  Vision  2010  and  supporting  Service  documents.  As  we  examined  the  impact  of  OS  on 
supportability,  we  found  a  number  of  government  agencies  and  contractors  who  touched  on 
various  benefits  on  Open  Systems  Architecture  (OSA)  and  elements  related  to  OSA  such  as 
COTS,  commercial  parts,  and  commonality.  What  we  found  was  enthusiasm  for  OS  and 
commercial  products.  What  we  didn’t  find  was  a  well-structured  set  of  guiding  principles  and 
some  supporting  facts  about  the  impact  of  OS  on  achieving  the  goals  of  focused  logistics. 

This  section  of  the  Report  is  organized  around  the  fundamentals  of  focused  logistics,  the 
relationship  of  these  fundamentals  to  OS,  the  identification  of  issues  in  this  area  and,  finally,  a  set 
of  recommendations  as  they  apply  to  both  legacy  systems  and  new  systems. 

TENETS  OF  FOCUSED  LOGISTICS 


The  four  tenets  of  focused  logistics  are  expressed  in  JV  2010  are: 

1 .  Reduction  in  logistics  footprint 

2.  Achievement  of  interoperability 

3.  Maintaining  the  operational  edge 

4.  Lower  cost  of  ownership 

REDUCTION  IN  LOGISTICS  FOOTPRINT 

As  the  demand  for  rapid  deployment  increases,  and  the  continued  need  to  support  the  mobile, 
expeditionary  forces  as  envisioned  in  JV  2010,  more  emphasis  will  have  to  be  placed  on  reducing 
the  logistics  footprint  and  supporting  fighting  units  on  arrival.  We  considered  the  impacts  of 
OSA  on  all  aspects  of  logistics  to  include:  parts,  test  equipment,  tech  orders,  as  well  as  the 
maintenance  teams. 

The  key  to  gaining  the  optimum  benefit  from  OS  lies  not  only  in  the  implementation  of  an  OSA 
but  to  the  degree  to  which  the  OS  As  are  standardized  and  commonality,  is  achieved  across 
multiple  but  similar  type  systems.  An  OSA  based  development  of  a  weapon  system/support 
system  will  enable  the  deployment  of  a  system  that  could: 

•  Have  commonality  of  hardware,  firmware  and  software  thereby  reducing  the  number  and 
type  of  spares  to  be  supported. 
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•  Result  in  substantial  size  and  power  consumption  reductions  due  to  multi-function  apertures, 
higher  levels  of  component  integration,  and  consolidation  of  multiple  component  cards  to  a 
single  card.  This  allows  more  function  or  component  capabilities  per  chassis. 

•  By  implementing  the  principles  of  OSA  in  the  IEWCS  coupled  with  commonality  and  the 
implementation  of  OSA  across  six  different  types  of  EW  systems  (both  ground  and  air),  army 
operational  units: 

-  Required  46%  fewer  operators,  65%  fewer  vehicles  and  60%  less  airlift  and  capacity. 

-  Could  share  testing,  operator  training,  and  overall  supportability  functions  due 
commonality  and  less  operational  specialization. 

-  Would  be  able  to  share  personnel  and  facilities  because  of  the  commonality  of 
maintenance  tasks  and  skills  required  to  support  IEWCS  subsystems. 

-  This  is  clearly  a  classic  case  of  what  is  envisioned  as  emphasis  is  placed  on  or  reducing 
the  tooth-to-tail  support  and  ultimately  the  overall  logistics  footprint. 

ACHIEVEMENT  OF  INTEROPERABILITY  AND  INTERCHANGEABILITY 

The  basic  premise  of  interoperability  as  it  pertains  to  focused  logistics  is  the  ability  to  share 
assets  in  order  to  meet  supportability  requirements  while  at  the  same  time  meeting  and  surpassing 
the  operational  effectiveness  needs.  Again,  the  implementation  of  an  OSA  across  multiple  types 
of  the  Army’s  EW  systems  resulted  in: 

•  Subsystem  and  component  interchangeability  across  the  Army’s  individual  units  and 
platforms. 

•  Ease  of  cross  training  and  flexibility  of  personnel  assignment  due  to  the  use  of  similar  display 
terminals  and  display  formats. 

•  Use  of  common  databases  thus  enabling  operators  to  achieve  sensor-to-sensor  cross  cueing. 

•  Increased  joint  and  international  theater  interoperability  through  the  incorporation  of  a  similar 
OSA  into  other  services  such  as  the  USMC  Mobile  Electronic  Warfare  Support  System. 

MAINTAINING  THE  OPERATIONAL  EDGE 

To  maintain  the  operational  edge,  we  must  field  and  support  systems  which: 

•  Provide  technological  superiority 

•  Quickly  adaptable  to  meet  unexpected/unplanned  threats 

The  OSA-based  development  of  IEWCS  resulted  in  a  highly  evolvable  and  fully  supported 
system,  which  permitted  easily  upgradeable  subsystems  and  components  to  meet  evolving  threats 
through  technology  insertion.  For  example,  this  provided  the  ability  to  incorporate  more 
powerful  processors  to  accommodate  more  computationally  intensive  algorithms.  Additionally, 
the  implementation  of  OSA-based  system/subsystem  permitted  easy  reconfiguration  of  each  of 
the  major  subsystems  to  meet  special  mission  needs. 


In  addition  to  having  an  OSA-based  system,  the  emphasis  on  currently  available  off-the-shelf 
technology  that  is  soon  to  be  available  provides  an  added  benefit.  This  focus  permitted  the 
IEWCS  Program  Office  to  develop  a  system  which  makes  possible  a  technologically  and 
operationally  robust  system  while  maintaining  the  flexibility  to  address  future  electronic 
battlefield  requirements  in  a  timely  manner. 

LOWER  COSTS  OF  OWNERSHIP 


In  addition  to  the  overall  operational  and  supportability  benefit  resulting  from  the  use  of  an  OSA- 
based  system,  there  are  clear  indications  that  there  are  significant  cost  savings  or  cost  avoidance 
benefits. 

For  example,  the  use  of  an  OSA-based  system  across  multiple  platforms  (both  ground  and  air)  for 
the  IEWCS  resulted  in  overall  total  Army  cost  avoidance  of  $1B.  Of  that,  approximately  55%  of 
those  savings  occurred  in  the  R&D  and  production  phase.  The  use  of  an  OSA-based  system 
coupled  with  maximum  commonality  resulted  in  a  reduction  of  cycle  time  for  the  engineering  and 
manufacturing  development  phase  of  1 8-39%  depending  upon  the  particular  platform. 

Generally  speaking,  there  is  already  existing  analysis  to  support  the  premise  that  overall 
Operations  and  Support  (O&S)  costs  can  be  reduced  through  the  use  of  an  OSA.  For  example,  in 
the  case  of  the  IEWCS  program,  O&S  costs  avoidance  over  a  20-year  period  is  expected  to  be 
$43 6M.  This  does  not  include  the  corresponding  cost  reductions  due  to  the  elimination  of  unique 
training  vehicles  and  maintenance  facilities  associated  with  having  six  different  legacy  systems. 

Similar  cost  savings  have  been  derived  from  other  platforms  that  have  considered  the 
implementation  of  OS.  In  96  dollars,  the  Air  Force  believes  that  it  reduced  its  O&S  costs  on  the 
F-15E  by  $140M  and  correspondingly,  the  Navy  has  estimated  cost  avoidance  savings  of  $1 17M 
on  the  AV-8. 

As  is  generally  recognized,  software  development  and  follow-on  support  has  clearly  become  a 
major  cost  factor  on  any  weapon  system.  One  way  to  counter  this  exponential  cost  growth  is  by 
taking  advantage  of  software  reuse.  In  the  Army’s  IEWCS  program,  almost  67%  of  the  software 
was  reusable  across  the  six  different  platforms.  But  even  more  telling  is  the  prediction  that  future 
updates  of  the  IEWCS  could  be  accomplished  with  figures  approaching  100%  reuse.  Not  only 
does  this  reduce  overall  costs  and  schedule,  but  it  also  reduces  risks  and  provides  for  a  more 
common  baseline  for  future  updates. 

In  another  instance,  Northrop  Grumman  used  commercial  equipment  in  an  Open  standard 
environment  for  radar  systems  being  developed  for  Unmanned  Aerial  Vehicles.  They  were  able 
to  achieve  an  80%  reuse  in  software  development  between  platforms  and  essentially  a  100% 
reuse  of  the  signal  procession  software  module. 

Full  implementation  of  DII  COE,  extended  to  include  real  time  applications,  could  be  the  vehicle 
to  drive  widespread  software  reuse. 
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While  COTS  and  OSA  are  not  the  same,  it  is  clear  that  in  many  cases  an  OSA  serves  as  an 
enabler  for  the  use  of  COTS.  This  obviously  leads  to  other  savings  because  of  the  ability  to: 


•  Enhance  competition 

•  Leverage  technology 

•  Achieve  economic  ordering  quantities 

This  has  an  effect  not  only  in  the  apparent  reduction  of  O&S  costs  but  also  in  R&D  and 
production  costs  as  well. 

OTHER  SUPPORTABILITY  ISSUES 


As  discussed  above,  the  implementation  of  OSAs  can  be  a  major  enabler  toward  meeting  JV 
2010  for  Focused  Logistics.  There  are  four  other  factors  of  the  supportability  issue,  which 
warrant  further  discussion  as  they  apply  to  the  impact  of  OSAs  and  commercial  technology. 
These  are: 

•  Parts  obsolescence 

•  Modification  updates 

•  Maintenance  concepts 

•  Logistics  process  to  include  the  support  of  logistics  IT  systems 

Parts  obsolescence  has  clearly  become  a  major  problem  affecting  operational  systems  today. 
This  impact  is  felt  not  only  in  the  legacy  systems,  but  in  weapons  systems  whose  IOC  is  within  a 
couple  of  years.  This  problem  has  been  brought  on  by: 

•  Aging  weapon  system  problems  due  to  longer  than  planned  operational  life 

•  Past  and  existing  acquisition  policies  and  procedures 

•  Diminishing  manufacturing  sources 

The  scope  of  the  problem  applies  to  the  analog/RF  market,  as  well  as  the  digital  market. 
Although  solutions  may  be  more  evident  in  the  digital  market  than  in  the  analog/RF  market, 
industry  believes  that  there  are  potential  solutions  on  the  horizon.  One  example  is  to  evaluate  the 
cellular  phone  market  and  similar  industries  for  solutions. 

The  implementation  of  an  OSA  by  itself  will  not  solve  the  parts  obsolescence  problem.  It  does 
serve  as  an  enabler,  as  previously  mentioned,  for  COTS/commercial  parts.  Secondly,  tied  to 
OSA  is  the  concept  of  Form,  Fit,  Function  and  Interface  (F^I).  There  is  a  real  opportunity  to 
work  toward  solving  this  problem  through  the: 

•  Potential  for  multiple  vendors 

•  Ease  of  replacement 

•  Ability  to  keep  up  with  technology  change  occurring  in  the  commercial  world 

One  note  is  that  the  benefits  achieved  are  generally  most  attributed  and  defined  for  the  electronic 
parts  market.  For  other  areas  such  as  mechanical  or  hydraulics,  more  work  may  be  required. 
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The  Joint  Aeronautical  Commanders  Group  has  taken  a  major  step  forward  in  addressing 
electronic  parts  availability  and  diminishing  manufacturing  sources  with  their  Performance  Based 
Business  Environment  (PBBE)  concepts,  but  there  clearly  has  to  be  a  cultural  change  in  both 
DoD  and  industry  in  order  to  be  successful.  It  appears  that  industry  is  already  moving  in  that 
direction,  if  for  no  other  reason  than:  “it  makes  good  business  sense.” 

Clearly  one  aspect  of  supportability  are  the  benefits  achieved  through  commonality  of 
modifications  and  updates.  The  Army’s  IEWCS  represents  a  classic  case  of  the  implementation 
of  OSA  across  multiple  types  of  systems.  Furthermore,  not  only  is  there  both  a  reduction  in  total 
life  cycle  costs  and  reduced  schedule,  but  OSA  readily  permits  technology  to  be  inserted  at  a  later 
date. 

While  not  necessarily  the  only  factor,  clearly  the  commercial  market  will  influence  the 
maintenance  concept.  There  is  already  underway  a  change  as  shown  below: 

•  3  levels  -  Historically 

•  2  levels  -  Currently 

•  1  level  -  Tomorrow 

In  the  non-weapon  systems  market,  such  as  the  medical  area,  DoD  has  already  moved  ahead  with 
the  Prime  Vendor/Virtual  Vendor  program  concepts.  One  aspect  of  these  new  concepts  is  the 
supply  chain,  insofar  as  you  go  directly  from  initial  supplier  to  user.  This  eliminates  many  of  the 
middleman  suppliers  and  distribution  organizations. 

Another  factor  driven  heavily  by  the  technology  explosion,  particularly  in  the  commercial 
market,  is: 

Mean-Time-To-Obsolescence  (MTTO)  <  Mean-Time-To-Failure  (MTTF) 

Digital  technology  is  changing  at  a  fast  rate.  At  the  same  time,  parts  are  becoming  more  reliable. 
The  DoD  appears  on  the  surface  to  be  more  influenced  by  the  digital  market  than  the  analog/RF 
market,  but  the  reality  is  that  the  problem  is  the  same  for  both  but  with  some  differences  in  the 
degree  of  impact.  The  problem  is  not  limited  to  legacy  systems:  we  are  already  seeing  parts 
availability  problems  appearing  in  the  F-22,  our  newest  fighter. 

The  implementation  of  OSA,  while  helping  to  promote  a  broader  source  of  parts,  is  not  in  itself  a 
cure-all.  Parts  replacements/updates  are  a  problem  for  the  services  to  solve  because  DoD  has 
historically  budgeted/procured/modified  based  upon  system/parts  failure,  not  upon  the  need  to 
ensure  an  adequate  source  of  parts.  When  availability  becomes  an  issue  in  programs,  DoD  has 
resorted  to  the  classic  source  of  utilizing  lifetime  buys:  clearly  not  the  most  cost  effective 
approach,  especially  in  periods  of  austere  budgets. 

Thus  supportability  has  to  be  considered  in  a  new  light.  In  the  past,  the  problem  was  that  parts 
failed  and  DoD  had  to  be  concerned  with  availability  and  the  impact  that  obsolescence  and 
diminishing  sources  had  on  the  supply  chain.  Today  the  problem  is  reversed  and  obsolescence 
becomes  a  driver  rather  than  a  factor  when  an  item  fails.  Essentially,  what  this  means  is  that 
DoD  very  well  may  be  forced  to  budget  and  adapt  its  supportability  concepts  to  address 
technology  refresh/insertion  rather  than  a  parts  failure.  In  this  environment,  the  traditional 
emphasis  on  configuration  control  to  support  build  to  print  will  be  replaced  by  F^I. 
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Finally,  there  is  the  issue  of  logistics  processes  and  the  supporting  IT  systems.  For  the  past 
several  years,  there  has  been  a  clear  emphasis  on  the  use  of  COTS  and  commercial  parts  for 
defense  related  systems.  Most  recently,  there  has  been  an  emergence  of  interest  in  the 
application  of  commercial  logistics  processes  and  commercial  IT  systems  to  support  the  logistics 
process.  The  emergence  has  been  accelerated  by  the  demand  to: 

•  Reduce  infrastructure 

•  Improve  response  times 

•  Eliminate  the  large  number  of  logistic  IT  systems  which  tend  to  be  both  stove-piped  and 
redundant. 

Yet  at  the  same  time,  there  is  no  single  organization  charted  to  solve  the  problems.  The  Joint 
Logistics  System  Center  (JLSC)  was  originally  charted  to  do  this,  but  JLSC  is  no  longer  in  that 
role. 

Unfortunately,  time  constraints  and  the  lack  of  any  earlier  detailed  analysis/studies  did  not  permit 
us  to  examine  the  implications  and  relationship  if  any  between  the  use  of  OSA  and  these 
processes  and  IT  systems.  However,  preliminary  analysis  indicates  that  visibility  becomes  even 
more  important  because  of: 

•  Greater  number  of  parts  available  for  substitution. 

•  Experience  (or  lack  of)  of  suppliers  with  regard  to  levels  of  support  required  for  their 
product. 

•  Inexperience  of  government  in  understanding  and  incorporating  commercial  warranties  and 
associated  terms  and  conditions. 

•  Implication  of  integrating  commercial  products  into  existing  or  planned  logistic  processes. 

•  Need  to  provide  adequate  documentation  to  ensure  interoperability  among  prime  and  sub¬ 
contractor  systems,  as  well  as  across  multiple  weapon  systems  which  employ  the  same  OSA 
or  share  in  common  modules/parts,  as  well  as  common  software/firmware 

IMPLEMENTATION 

There  are  a  number  of  factors  that  will  dictate  the  level  of  implementation  of  OSA.  They  are: 

A.  Overall  objectives  of  the  program 

B.  Technical,  costs,  and  risk  impact 

C.  Physical  limitations 

D.  Type  of  system 

E.  System  maturity,  i.e.  where  it  is  in  the  acquisition  cycle 

In  any  case,  the  decision  to  implement  OSA,  particularly  on  legacy  systems,  must  be  supported 
by  a  sound  business  case.  For  new  systems  still  in  the  conceptual  stage,  the  application  of  an 
OSA  at  the  highest  level  may  be  the  more  prudent  choice. 
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To  accomplish  this,  the  program  manager/program  executive  officer  must  have  total  performance 
responsibility  for  the  system/sub-system  over  its  life  cycle.  This  was  clearly  a  dominant  factor  in 
the  IEWCS  since  the  Army’s  PEO  for  IEW  had  total  responsibility  for  all  of  the  systems  involved 
and  for  R&D,  production,  and  follow-on  support. 

In  contrast,  the  Joint  Tactical  Radio  (JTR)  program  as  currently  conceived  does  not  offer  a 
program  with  the  same  level  of  management  responsibility  and  authority.  While  the  JTR 
program  office  will  be  responsible  for  the  R&D  and  establishment  of  standards  and  protocols, 
each  service  will  be  responsible  for  their  own  acquisition  and  logistics  concepts.  This  raises  a 
number  of  questions  about  the  “jointness”  and,  more  specifically,  about  the  ability  to  save  dollars 
in  the  supportability  area. 

The  commercial  world  can  certainly  affect  the  decision  process  with  regard  to  the  level  of  OSA 
that  will  be  or  should  be  implemented.  Generally  speaking,  the  influence  of  the  commercial 
market  on  OSA  decreases  as  you  go  from  the  board/component  level  to  the  weapon  system  level. 
The  final  decision  on  what  level  of  OSA  to  pursue,  whether  for  a  new  system  or  a  legacy  system, 
will  depend  upon  the  factors  previously  discussed  above. 

The  commercial  market  will  continue  to  have  a  profound  effort  upon  supportability.  This  effort 
will  be  driven  by  a  number  of  factors  to  include: 

A.  Exponential  explosion  in  technology 

B.  Expanded  market  beyond  the  IT  domain  to  include  cellular  phones  and  personal 
communication  devices 

C.  Increasing  reliance  on  commercial  vendors  including  a  broader  base  to  access 

Our  study  found  that  industry  believes  that  it  takes  considerably  more  resources  to  develop 
custom  designs  for  embedded  systems/sub-systems  as  typically  found  in  most  weapon  platforms 
and  for  the  applications  normally  associated  with  support  systems.  Most  companies  that  we 
interviewed  felt  that  the  extra  effort  required  to  use  commercial  systems/products  or  through 
some  level  of  implementation  of  an  OSA  was  relatively  small  compared  to  costs  associated  with 
unique  solutions  or  design  of  specific  products.  As  one  major  defense  contractors  pointed  out: 

“However  good  commercial  standards  are  today,  we  also  need  to  be  cognizant  of 
the  additional  effort  to  develop,  test  and  maintain  fielded  systems  using 
commercial  standards  over  the  product  life  cycle.  This  is  where  OS  standards 
will  play  an  important  role  -  to  define  process  standards,  as  well  as  the  physical 
ones  which  maintain  OS  performance,  but  in  such  a  way  that  contractors  can 
interchange  their  products  at  a  lower  life  cycle  cost  to  the  government.” 

CONTRACTOR  LOGISTICS  SUPPORT 

While  there  seems  to  be  a  general  consensus  that  the  implementation  of  an  OSA  can  improve 
supportability,  there  are  two  other  factors  that  must  be  considered. 


The  first  is  the  impetus  of  DoD  to  move  to  full  Contractor  Logistics  Support  (CLS).  In  this  case, 
the  decision  of  what/how/if  to  implement  an  OSA  on  weapons  system  will  largely  be  driven  by 
the  prime  contractor  who  will/should  assume  full  responsibility  for  CLS  as  part  of  their  overall 
contract. 

The  issue  is  how  do  you,  or  whether  in  fact  you  should,  enforce  OSAs  on  programs  utilizing 
CLS.  This  is  compounded  by  the  fact  that,  more  and  more,  DoD  is  promoting  the  concept  of 
Total  System  Performance  Responsibility  (TSPR).  Thus,  it  becomes  a  real  issue  of  how  much 
DoD  should  direct  when  in  fact,  under  many  integration/CLS  contracts,  TSPR  is  a  major 
requirement. 

The  government  needs  to  weigh  this  against  the  potential  that  either  the  government  moves  away 
from  CLS  or  a  particular  system  on  the  contract  changes  or  goes  away.  It  is  clear  that  as  the 
acquisition/support  strategy  is  being  developed  for  either  a  new  system  or  a  legacy  one,  this  issue 
must  be  addressed. 

Notwithstanding  this  issue,  however,  we  have  found  that  many  companies  are  moving  to  OSAs  in 
some  form,  independent  of  any  direction  from  the  government.  They  are  doing  it  for  business 
reasons,  the  least  of  which  is  to  be  competitive. 

The  second  factor  that  takes  on  significant  importance,  particularly  in  the  case  of  legacy  systems 
where  full  CLS  is  not  implemented,  is  the  issue  of  asset  visibility.  While  the  Services  are  talcing 
significant  steps  to  improve  visibility  under  the  Total  Asset  Visibility  (TAV)  program,  there  are 
real  questions  of  adequate  visibility  at  the  inventory  control  points,  air  logistics  centers,  and  other 
places.  The  problem  is  compounded  by  an  extremely  large  number  of  stovepipe  systems  and  the 
lack  of  shared  databases. 

OSD  and  the  services  must  take  action  to  ensure  that  they  have  visibility  horizontally  across  these 
stovepipes  and  that  they  take  advantage  of  IT  technologies  such  as  data  mining  and  data 
warehousing  to  achieve  shared  data  bases. 

PROGRAM  MANAGEMENT 

The  implementation  of  OSAs  to  improve  supportability  requires  total  management  authority 
cradle-to-grave.  One  of  the  major  factors  in  the  success  of  the  IEWCS  program  discussed  earlier 
was  the  factor  that  the  PEO  had  responsibility  not  only  for  new  systems  but  for  legacy  systems  as 
well,  and  was  responsible  for  the  total  life  cycle  of  those  programs. 

While  the  department  has  made  great  strides  in  addressing  the  total  cost  ownership  on  programs, 
it  is  clear  that  supportability  must  continue  to  be  emphasized  as  an  up-front  requirement.  In 
addressing  supportability  requirements  where  OSAs  are  not  stand-alone  solutions,  other 
approaches  such  as  COTS  and  commonality  also  influence  supportability.  In  addressing  the 
implementation  of  OSAs,  the  department  needs  to  recognize  that  while  this  approach  may  help 
alleviate  parts  availability  problems,  the  decision  to  implementOSAs  must  be  considered  in  the 
context  of  overall  maintenance  and  support  concepts.  This  can  only  be  successful  if 
supportability  is  considered  in  its  totality  up  front. 
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RECOMMENDATIONS 


In  spite  of  what  many  may  perceive  as  the  technical  or  programmatic  hurdles  associated  with  the 
implementation  of  OSA,  the  OSTF  has  concluded  that  the  real  challenges  are  in  the  management 
area.  There  are  a  number  of  actions  that  must  be  undertaken  if  we  are  to  realize  the  full  potential 
of  OSA  and  commercial  products  in  achieving  focused  logistics  for  JV  2010.  These  are: 

1.  The  Program  Executive  Officer/Program  Manager  must  be  given  total  “cradle  to  grave” 
responsibility  for  their  system/systems.  The  real  success  of  a  program  depends  upon  having 
one  person  in  charge  that  can  address  everything  from  requirement  definition, 
development/technology  insertion,  and  production  to  follow-on  support.  This  was  clearly  a 
major  element  in  the  success  of  the  Army  IEWCS. 

2.  Establish  a  mechanism  for  transporting  concepts/architecture/interface  requirements  across 
multiple  platforms/services.  At  a  lower  level,  the  Joint  Aeronautical  Commander  Group 
(JCAG)  has  accepted  that  task  as  it  pertains  to  the  implementation  of  the  JTA  and  the  lower 
level  standards  required  to  meet  F^I  for  aeronautical  systems.  There  is  clearly  much  more 
that  can  be  done  in  this  area. 

3.  Increase  support  for  the  work  already  being  accomplished.  This  would  not  only  include  the 
initiatives  underway  within  the  JCAG,  but  also  those  initiatives/studies  being  accomplished 
by  the  OSTF. 

4.  Significantly  increase  our  emphasis  on  improving  logistics  processes  as  well  as 
eliminating/improving  the  logistic  IT  systems  we  have  today.  If  we  could  do  only  one  thing 
in  this  area,  probably  the  most  important  initiative  would  be  to  implement  the  IT  tools 
required  to  provide  horizontal  visibility  across  the  multiple  stovepiped  system.  This  has  to  be 
done  across  all  of  the  Services.  To  date,  there  is  no  joint  or  common  initiative  that  would 
assure  the  level  of  visibility  needed  to  support  existing  or  future  systems. 
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DSB  TASK  FORCE  ON  OPEN  SYSTEMS 
APPENDIX  G 


OBSERVATIONS  ON  THE  JOINT  TACTICAL  RADIO  SYSTEM 

by  Chris  Wain 


Introduction 

Although  small  in  scope,  the  JTRS  program  offers  more  opportunities  to  change  the 
character  of  DoD  communications  systems  than  programs  several  times  its  size.  In 
addition,  with  small  to  moderate  changes,  it  can  serve  as  an  Open  Systems  (OS) 
Process  exemplar. 

In  2007,  80%  of  the  communications  force  structure  will  be  made  up  of  legacy  systems. 
Of  the  20%  new  content,  80%  is  in  less  than  major  systems  development.  Of  that  80%, 
80%  is  addressable  by  JTRS  -  either  in  terms  of  development  process  or  actual 
deliverable  end-items.  To  be  most  effective  from  an  OS  Process  perspective,  some  fine 
tuning  to  the  program’s  role,  scope,  and  management  construct  is  required. 

For  JTRS  to  achieve  true  interoperability  as  envisioned  in  the  OS  Process,  the  JTRS 
Program  Office  must: 

•  Have  a  higher  level  of  empowerment; 

•  Divest  responsibilities  which  conflict  with  its  “Plug  &  Play  change  agent”  role;  and 

•  Consider  waveforms  as  well  as  technology  insertion  and  supportability. 

Management 

The  strategic  context  for  JTRS  needs  to  be  made  visible  by  explicitly  tying  the  JTRS 
architecture  process  to  Joint  Vision  2010  (JV2010)  interoperability  demands,  the  JTA, 
and  the  C4ISR  Framework.  These  ties  are  missing  and  this  leaves  JTRS  looking  like  a 
management  “best  practices  initiative”  rather  than  a  core  program. 

Service  TOA  should  be  transferred  to  the  Army  for  execution  under  DAE  auspices  with 
fenced  funding.  The  current  contributive  funding  model  has  a  long  history  of 
destabilizing  programs,  with  late  delivery  the  least  of  the  negative  outcomes. 

As  it  is  currently  funded,  JTRS  funding  is  insufficient  to  support  efficient  and  operationally 
relevant  deliveries.  Early  funding  should  be  increased  by  a  factor  to  1 .5  to  2  to  support 
parallel  prototype  deliveries  to  the  test  environment  on  3  month  centers. 

The  JTRS  program  compliance  enforcement  responsibilities  are  unsupported  by 
effective  control  mechanisms  and  interfere  with  making  the  program  a  source  of 
solutions  for  Service  program  managers.  These  responsibilities  should  be  divested  to 
the  ASD/C3I  technical  staff 
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Fine  Tuning  the  Planning  and  Architecture  Development  Activity 

The  tie  between  JTRS  and  higher/lateral  communications  architectures  is  weak.  (Higher 
level  architectures  may  be  missing.)  For  JTRS  to  be  included  or  referenced,  the 
Program  Office  must  actively  participate  in  higher/lateral  architecture  development  to 
include  waveform  development  activities. 

The  Program  Office  has  not  identified  a  roadmapping  tool  and  should  do  so.  The 
potential  complexity  of  successful  outcomes  demands  it.  Likewise,  the  Program  Office’s 
databases  on  Service  radio  modernization  planning  are  largely  unpopulated  and  what 
information  and  data  are  available  are  uncosted/unphased  and  may  not  represent  the 
Service’s  positions.  The  financial  leverage  offered  by  JTRS  cannot  be  broadly 
demonstrated  without  this  information.  This  is  a  major  collection  effort,  but  it  essential  for 
overall  program  success.  In  a  similar  vein,  there  is  no  visible  plan  to  target  high 
visibility/high  payoff  opportunities  first.  The  Program  Office  should  develop  a  delivery 
schedule  (by  segment/domain)  which  supports  early  successes  in  the  best  understood 
areas. 

Testable  Prototype  Executive  Agent  Role 

The  JTRS  timeline  for  prototype  deliveries  is  too  slow.  The  schedule  won’t  underwrite 
strategic  business  change  (no  sense  of  urgency);  won’t  result  in  new  radio  deliveries  in 
meaningful  numbers  in  time;  and  can’t  demonstrate  early  successes  before 
Administration  change.  Since  effective  strategic  change  is  best  built  on  a  series  of  rapid- 
fire  short-term  success  which  ultimately  blend  into  a  long-term  culture  shift,  prototypes 
should  be  delivered  on  3  month  plan  (versus  the  6  month  plan,  12  month  funding  profile) 
to  create  the  visible  evidence  of  constant  improvement. 

The  testing  community  is  antagonistic  toward  the  JTRS  accelerated  development 
approach.  SECDEF/Legal  relief  from  the  usual  testing  methodologies  should  be 
granted.  (Acquisition  reform  precedents  exist). 

Exit  criteria  for  prototype  readiness  for  test  and  prototype  test  success  have  not  yet  been 
established.  The  Program  Office  should  start  developing  these  criteria  now  using 
INTEROPERABILITY  as  the  guiding  principle,  not  slavish  adherence  to  arbitrary 
standards. 

Staff  Commentator  on  Service  Program  Activities  Scope 

“Commentator”  is  a  not  a  value-added  role  for  the  JTRS  Program  Office.  The  Program 
Manager  works  for  the  Army  which  puts  the  PM  in  an  invalid  position  from  which  to 
comment  on  sister  Service  compliance,  and  the  PM  has  no  believable,  explicit 
enforcement  mechanism  for  dealing  with  non-compliant  programs  in  any  case.  Making 
JTRS  responsible  for  compliance  monitoring  casts  the  JTRS  Program  Office  in  a  “cop” 
role  when  what  is  really  needed  is  for  JTRS  to  be  viewed  by  PMs  and  Services  as  a 
valued  resource.  JTRS  architectural  compliance  duties  should  be  moved  to  the  ASD/C3I 
technical  staff  and  “fire-walled”  from  JTRS.  JTRS  should,  however,  lead  the  process  of 
defining  an  explicit  model  for  architectural  compliance  (entrance  criteria). 
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The  JTRS  Program  Office  role  (relative  to  other  DoD  agencies)  in  the  communications 
standards  process  is  undefined.  The  program  should  be  the  principal  OSD  POC  for 
participation  in  the  industrial  radio  standards  dialog. 

Conclusions 

The  Joint  Staff  should  continually  and  consistently  demand  JTRS  as  a  JV2010  enabler, 
for  reasons  of  both  capability  and  footprint.  The  JROC  should  use  JTRS  ORD  as  a 
model  for  other  OS  enabled  capabilities.  (The  MNS  should  be  waived  -  radios  aren’t  a 
mission).  The  Vice  Chiefs  should  use  JTRS  as  a  comparable  when  reviewing  other 
capability  requirements  before  presentation  to  JROC.  The  Services  should  increase 
their  participation  in  operational  architecture  development  to  take  best  advantage  of 
JTRS  implementations.  The  Military  Departments  should  assent  to  TOA  transfer  to 
enable  realistic  JTRS  execution.  Industry  should  maintain  its  active  participation  in  the 
forums,  but  should  demand  active  government  leadership. 

The  DAE  should  agree  to  make  JTRS  a  1 D  program  for  its  leveraging  importance  to  the 
Department.  This  should  be  a  championship  action  rather  than  an  increase  in  oversight. 
The  DAE,  ASD/C3I  and  SAEs  should  protect  the  program  to  ensure  acquisition  reform- 
based  methodologies  are  given  a  chance  to  succeed.  The  Vice  Chiefs,  DAE,  and  SAEs 
must  demand  greater  attention  to  supportability  issues  (assign  a  DPML).  The  DAE  and 
SAEs  should  develop  a  two  tier  incentive  structure.  JTRS  compliant  programs  should  be 
given  extraordinary  acquisition  process  and  budgetary  process  relief.  JTRS  responsive 
contractors  should  be  given  greater  opportunity  for  performance-based  profit.  The  DAE 
should  seek  legislative  relief  from  testing  processes  which  are  JTRS(OS)  unfriendly. 
ASD/C3I  must  take  on  the  compliance  monitoring  role  to  prevent  JPO  from  becoming 
“them.”  The  OSD  Comptroller  should  agree  to  putting  funds  in  “D”  program  element  and 
use  the  power  of  the  PBD  process  (with  the  advice  of  DAE)  to  prevent  stovepiped  end- 
run  programs. 


rev  15Sep98 


page  3 


